Monthly Archives: October 2012

Reading ZEVO forums at I ran into a nifty way to solve most of ZFS-over-AFP-sharing problems. To recap: I have a few zfs systems defined on my server pool. When I enable file sharing, only some of those systems show up as volumes on the network.  There seems to be no clear indicator of why some systems do show up as volumes so users can connect to them and others do not. Form reading comments around the web it looks like Apple is now hardcoding some HFS file system properties into the software, which delegates alternative files systems to the role of second-class citizens and breaks functionality (including AFP sharing) for them. Bad Apple.

The solution is to trick the AFP server into believing that every file system it sees is HFS: a small library I installed on the server and now all volumes show up in AFP network browser on the client machine.

I spent a weekend trying to get a client machine to automount a volume from the server via samba. I need three users on the client to be able to access (read/write) files on the server. I want to preserve the information about the file creator, so each user has his/her own login credentials for the server, — I don’t want to have just one user login for everyone. I need the volume to be mounted three times, each time for a different user with different login credentials. I need the mount point to well-defined — your traditional “connect to server” in Finder does not work to well, it uses /Volumes as the mount location and then names each new volume mount sequentially, e.g., Media, Media1, Media2, etc.

One solution that looked promising is to automount the volume into each of the users home directory under the user’s server login credentials. That volume would look like another folder with all files owned by the user. I looked over the autofs guide and created a direct map file that looked like this:

/Users/user1/Media -fstype=smbfs,soft ://user1:pwd1@server.local/Media
/Users/user2/Media -fstype=smbfs,soft ://user2:pwd2@server.local/Media
/Users/user3/Media -fstype=smbfs,soft ://user3:pwd3@server.local/Media

It looked like it was supposed to work. And it worked. For two users. For the third one, the mounted directory assumed root ownership and was unaccessible. I relaunched automount a few times and suddenly all three users can access their respective Media folders. I rebooted the client machine, now users 2 and 3 can see, mount, and use the folders, but user1 could not. I spent most of the day trying to figure out why the mounting was so unstable. Finally, I gave up on this approach.

My current solution, the one that seems to work reliably, is to create an indirect map for every user into a hidden folder somewhere on the startup disk

sudo mkdir /UsersVolumes
sudo chflags hidden /UsersVolumes

add this to /etc/auto_master

/UsersVolumes my_indirect_map -nosuid

and then /etc/my_indirect_map looks like

user1 \
     /Media -fstype=smbfs,soft ://user1:pwd1@server.local/Media

user2 \
     /Media -fstype=smbfs,soft ://user2:pwd2@server.local/Media

user3 \
     /Media -fstype=smbfs,soft ://user3:pwd3@server.local/Media

I also put a soft link in every user’s home folder to the appropriate Media folder.

cd /Users/user1
ln -s /UserVolumes/user1/Media
chmod -h 0700 Media

The last line should ensure that only user1 will be able to access the link and trigger the mount.