beatworm.co.uk

NFS is a good protocol to use for sharing filesystems between UNIX-like computer systems. Mac OS X 10.x will happily serve and mount network filesystems using the NFS protocol out of the box. If you are working from the shell, you can just mount nfs exports, using the mount command in the usual manner, and assuming your NFS is appropriately configured for permissions, it should Just Work. Assuming a mount point of an empty folder in your home directory called mountpoint, you can issue a command like

mount server:/path/to/share ~/mountpoint

and you’ll get your network directory mounted there just like you were using any old UNIX system.

There are problems with using this straightforward approach though, it confuses the Finder. If you are using a mountpoint somewhere within the Finder’s idea of the visible filesystem, it will probably notice this new curio fairly sharply. Your mountpoint directory will probably be re-rendered with a network alias icon rather than a folder, and if you have the Finder sidebar preference to ’show connected servers’ enabled, you’ll probably get a network icon in there representing the nfs mount, complete with little ‘eject me’ widget, just like a removable media filesystem. You can’t eject it with this widget though, you need to unmount it from the shell, using the usual umount command.

When you do this you’ll probably find that you still have a ‘connected server’ sidebar item, replete with non functional eject widget. Clicking on it tends to throw you into the ‘Computer’ Finder view, occasionally you might get a grumble from the Finder about the volume being removed. Usually not though. You might be able to drag the null ‘volume’ to poof or to the trash, you might not. Even if you manage this it sometimes pops back up again a few seconds later, still quite useless. Force Quit -> Restart Finder usually sorts this, but again not always. Sometimes it seems to need a reboot. This entire state of affairs is most unsatisfactory. It’s probably better to keep mountpoints for shell sessions, or scripts somewhere the Finder won’t look for them, like under /usr/local or /mnt . This isn’t any use if you want to be able to use this filesystem from any GUI applications.

A better approach to ad hoc network mounts is to use the Finder to control the mounting. Using the ‘connect to server’ option in the ‘Go’ menu, or the shortcut command-k , and the odd looking URL

nfs://server/path/to/share/

This gets you a network icon for a new volume in the sidebar, again replete with eject button. This time around though the icon works, you can eject it using it’s control or drag it to trash to unmount. The Finder has created a mount for you under /Volumes/ with a unique mount point name that has been generated from the remote hostname. You can use this mount as you’d expect from shell sessions. What’s even better, the Finder will react more appropriately to shell level changes, closing open views and removing the volume icon if you unmount it, informing you that it’s in use if you try to eject it. The mount is interruptible and the Finder will time out and ask to disconnect in the event of networking problems. For transient network shares, the Finder’s connect to server feature looks like the way to go.

With network shared volumes, it’s common to want some persistent shares, for situations like common project folders, networked personal directories or backup volumes. On UNIX like systems you might add entries to the system fstab table, and have them mounted at boot time via the startup scripts. You could do something similar in Mac OS X, or you could use login scripts to mount shares using the previously discussed approaches. There is a third interesting way to use NFS shares in Mac OS X, you can use the system automounter.

The automounter is a system daemon that is launched at boot time, via SystemStarter. It’s job is to manage network filesystem mounts on-demand. Assuming that the line

AUTOMOUNT=-YES-

is present in /etc/hostconfig , the NFS service in /System/Library/StartupItems/NFS/ spawns several instances of the automounter during the boot process to handle different kinds of network filesystems. The one that is used to manage dynamic NFS mounts is called like this

automount -m /automount/Servers -fstab -mnt /private/Network/Servers
-m /automount/static -static -mnt /private/var/automount

This invocation is responsible for creating two ‘filesystems’ which appear can be seen as

automount -fstab [PID]

and

automount -static [PID]

in the output of df . The automounter will create special symbolic links within these filesystems that represent network filesystems, mounting them transparently as they are accessed and then automatically unmounting them after a certain amount of idle time. The ‘magic’ used to differentiate these symbolic links from normal links, is simply that they have the ’sticky bit’ set.

The -m argument supplied to the automounter is used to specify the ‘map’, which is a list of nfs exports and mount options and locations. The invocations above make use of the ’special’ map types -static and -dynamic which generate map information from system fstab data.

OS X, of course doesn’t actually store it’s fstab data in a traditional /etc/fstab flat file by default. Like many other system configuration variables, this data uses the NeXT-inherited NetInfo directory service. A dictionary called ‘mounts’ is used to hold this filesystem information, it contains a dictionary for each mount point with the following structure, shown below in nidump ‘raw’ format. The keys mostly correspond to the fields found in a more traditional fstab file entry.

{
  "name" = ( "mounts" );
  CHILDREN = (
    {
      "dir" = ( "/mnt/some/local/mountpoint" );
      "dump_freq" = ( "0" );
      "name" = ( "server:/path/to/share" );
      "opts" = ( "net", "-P", "-i", "-s", "rw" );
      "passno" = ( "0" );
      "vfstype" = ( "nfs" );
    }
  )
}

By default, the /mounts dictionary won’t exist on a fresh OS X client. There are a few ways you can manipulate NetInfo to create this data, using the NetInfo Manager GUI application in /Applications/Utilities/ or using the command line utilities niutil or niload . “niload” is the best way to approach this task I think, as it has a very nifty shortcut feature - it ’speaks’ traditional flat file format for a number of dictionaries, and will convert input from a normal UNIX flat file format for many dictionaries such as aliases, fstab, group, hosts, passwd, and quite a few others.

Using the command

 niload fstab . < foo.txt 

you can load the contents of the file foo.txt into the local netinfo database, and assuming that foo.txt contains fstab formatted information, it will populate the mounts dictionary for you with the correct keys. You will need admin privileges to write to the NetInfo database, just use sudo . The example dictionary above would correspond to foo.txt being a flat file with the following content.

 server:/path/to/share   /mnt/some/local/mountpoint   nfs   net,-P,-i,-s,rw   0   0 

After loading it , the command

 nidump -r /mounts / 

should demonstrate the raw dictionary form from above. The various client options are the usual things, and can be found from the mount_nfs man page. The net option is a special option for the automounter. This causes the local mount point field to be ignored, the symlink will appear within the automount -fstab filesystem using a generated path of the form server/path/to/share .

The default automount -fstab filesystem configuration maps to /automount/Servers as noted above. OS X has a symbolic link set up /Network/Servers/ that points to this location, and using the net option for your mount will cause your network volumes to be mounted, neatly and transparently on demand within the Finder’s Network hierarchy, and subsequently unmounted automatically after an idle period. The example above would correspond to a Finder location of /Network/Servers/server/path/to/share/

Mounts defined without the net option would create the symbolic link using the local mountpoint path argument, which would point to a similarly named “trigger” link in the location defined by the -static automount filesystem.

Once you’ve configured all of this, a quick SIGHUP to the automounter processes, should set all this up to work for your next login. I usually reboot the system at this point, however, just to be double sure it’s all caught.