Network shares
After setting up ZFS, I need to set up network shares and connect them to our home computers.
I originally chose NFS because of its simplicity to set up.
zfs set sharenfs=on tank/Media zfs set sharenfs=on tank/twiddle zfs set sharenfs=on tank/backups
That’s it for the OpenSolaris side of things. The only thing left to do is connect these NFS shares to my Mac. This is a simple task. Although I could mount them like any other server, I instead chose to use the automount facility provided by Directory Services (Note: this feature has changed in Snow Leopard). This way, the share is mounted when it is needed—a helpful tool when I am using a share for my iTunes music.
Directory Utility showing two NFS shares to be automounted
One big disadvantage of NFS, though, is that it shares based on user id. That is, user id number 1000 on the client will connect as user id 1000 on the NFS server. The practical implications of this is that each client computer should have unique user ids. Unfortunately, without a common user management system like NIS or LDAP, managing unique users across independent clients very quickly becomes tedious.
One alternative to NFS is to use CIFS/SMB. CIFS/SMB is normally used to make shares accessible to Windows computers, but it can also be used when one needs to maintain separate user accounts on server and client machines. In my case, I have two OS X computers, each with the primary user account #501. In this case, I can set up two user accounts on the file server and use SMB to access them from the Macs.
Setting up CIFS/SMB is not terribly complicated, but it does require installing a couple of packages.
pkg install SUNWsmbs SUNWsmbskr
Next, enable the smb server:
svcadm enable -r network/smb/server
And finally, set the ZFS mount to use smb:
zfs sharesmb=name=Media tank/Media zfs sharesmb=name=twiddle tank/twiddle
At this point I could connect to the shares from my Mac via SMB, but I noticed that newly created files had no permissions. The solution was to set up ACLs on the file server.
/bin/chmod -R A=owner@:full_set:d:allow,\ owner@:full_set:f:allow,\ everyone@:rxaARWcs:d:allow,\ everyone@:raARWcs:f:allow \ /tank/Media /tank/twiddle
This simply sets an ACL that allows the owner full access and gives read access to everyone else. Note that this command uses /bin/chmod, and not the OpenSolaris default of /usr/gnu/bin/chmod. For more details on ACLs, see the excellent posts at Daz’s bits and bobs.
On the file server, I have two users (john_remote and karen_remote), both members of the same group (remote), that I use for SMB sharing. I changed the ownership and group of the files that are shared on the file server, and I can now connect from the Macs with no problem. Thinking longer term, the SMB shares have the further advantage of still being usable as computers are added or replaced. The key is just the user id and password.
about 10 months ago
Thanks for this John; really helpful!
Quick question: what version of OpenSolaris are you running? 2008.11? Am having some problems getting cifs running that I suspect is a consequence of running a recent build.
about 10 months ago
Yes, I’m running 2008.11. I had some problems getting it running myself. However, I started the client service, and the server then started with no problems. Then I turned off the client, and I haven’t had any problems (but I haven’t restarted yet).
I have found a whole lot of helpful info all over the Internet and especially at sigtar.com.
about 10 months ago
It took me awhile, but I finally got cifs running.
Another question, as I’m stuck on connecting: why did you create *_remote users and the “remote” group? Did using your Mac user names/groups not work?
about 10 months ago
Hmm, that might be confusing: I meant “using the same user names/groups on both the Macs and the server”.
about 10 months ago
One more weird thing: I had to reboot. I now can’t restart the cifs server, even with the “turning the client on first” trick. Sigh …
about 10 months ago
@Bruce
I’m glad you got CIFS running. There is no technical reason I used different user names on the file server (different from the Macs). Although I could have used the same names, I chose new ones for the following reasons:
1) I already had an admin user account on the file server with the same name as on one of the Macs.
2) I wanted a non-admin user accounts on the file server.
3) With specific remote users and a remote group on the file server, it’s easy to keep track of who does what on the file server, and it’s easy to handle the future cases of new computers or users connecting to the file server.
All that being said, if I were using the file server to share user accounts (which I am not), then, of course, I would use the same user names.
about 10 months ago
@Bruce
We had a bad storm come through last night, and I lost power. I noticed today that, like you, the smb server was not running. I did manage to get it running though. I hope my methods work for you.
# svcadm disable network/smb/server
# rem_drv smbsrv
Invalid argument
Cannot remove major number binding for 260
# add_drv smbsrv
# svcadm enable -r network/smb/server
# svcs | grep smb
online 20:59:18 svc:/network/smb/server:default
#
Although I don’t think it was key to my success, earlier I did reimport the server manifest (svccfg import /var/svc/manifest/network/smb/server.xml).
about 10 months ago
I got it working again too, but don’t exactly know how! Hopefully this problem gets fixed in the 2009.06 release.
Anyway; I get it now on the permissions. With CIFS you effectively have a parallel permissions model.
about 7 months ago
Why not install OpenDS or OpenLDAP in a Solaris Zone? It’s pretty straightforward and as I recall with my Mac it is pretty easy to configure the Mac to use the OpenLDAP/OpenDS server for authentication.