NFS exports on Leopard

If you have several "unixy" workstations on your network that need to talk to your Mac, you'll likely want to use NFS. In my case, I have a few Linux machines around and also an old SGI O2, that I keep around mainly for nostalgia reasons (I sat at one throughout my grad school years, and simply loved it).

You may have seen this already elsewhere, but I found it very useful last week (when I finally moved over my main office Mac Pro over to Leopard) so I thought I'd write about it. On Leopard, setting up NFS exports is much easier than older versions of OS X. This is mainly because Apple eliminated NetInfo Manager which is what one had to use before for achieving something like this.

All you have to do is set up a file called exports in /etc with the proper NFS export information. For example, my /etc/exports looks like:


/nfs -ro -mapall=nobody -network 134.88.50 -mask 255.255.255.0
/nfs -maproot=root -network 192.168.0 -mask 255.255.255.0

You can create this file by simply typing: sudo nano /etc/exports in the Terminal application. So, what exactly is happening here? First of all, my NFS export directory is nfs and is located at the root level of my Mac's hard drive. Now, on my office's internal network (192.168.0.X) I am allowing all my systems full access to the exported directory. While on the external Physics department network (134.88.50.X) I am allowing only read-only access to the same. Of course, you may have different needs and so you'll want to modify this for your exports, but this is an example of the basics that anyone may want.

Next, you need to start the export by launching the NFS daemon. All you have to do here is type: sudo nfsd enable. You can check if indeed the appropriate exports are working, by typing: showmount -e. For example, on my Mac this yields:


Exports list on localhost:
/nfs 134.88.50.0 192.168.0.0

And you're done with the export set up! Thats it!

To mount the exported directory on a client machine (for example on the SGI O2) you can simply use the mount command. For example, I used: mount -t nfs 192.168.0.100:/nfs /mnt. The 192.168.0.100 is the address of my Mac Pro on the internal network. And mnt is the mount point I'm choosing on the SGI. Its really that simple ..

Comments

Don't use NFS. Use SSHFS

Yeah, I once used NFS for accessing remote Unix filesystems from my Mac, but I got sick of it. NFS is unreliable (especially when going outside your local network), insecure (passwords sent in clear text), and difficult to set up (as you can tell from this blog entry). I had a little better luck with AFP and Netatalk, but it was still buggy. Recently I discovered MacFUSE with SSHFS. It works so much better! Very secure, easy to use, and extremely reliable. It's all free and open-source, too. I strongly recommend giving SSHFS a try before wasting time debugging NFS export files.

You shouldn't have to issue "sudo nfsd enable"

You shouldn't have to issue

sudo nfsd enable

as /System/Library/LaunchDaemons/com.apple.nfsd.plist detects this and does so automatically.

However, the boot process doesn't reliably export it, and I sometimes have to issue

sudo nfsd reload

I think it is a disk arbitration issue. The niload way was clunkier but it always worked at least.

The new NFS by the way is now Kerberized, though I have no clue as to how to implement that.

Re: Kerberized NFS

Hi Bill,

There is an Apple TechDoc article that discusses this:

http://docs.info.apple.com/article.html?artnum=306694

Hope that helps,

Dave

Passwords are never sent when using NFS

Passwords are never sent in the clear with NFS. In fact, passwords are never sent on the wire when using NFS at all.

When using SYS authentication (which is the most common), the authentication is done at mount time and is done by based one the UID of the user requesting to mount an NFS volume. No password is needed, and this why NFS with SYS authentication is not secure (any one with a laptop can spoof any UID).

When using GSS authentication (NFS v3 and NFS v4), Kerberos is used to authenticate the user and, again, no password is ever sent.

With the help of Apple, I've

With the help of Apple, I've managed to get NFS working on 10.5 and have worked around a few bugs with exports and automounting.

I've posted a full accounting here

NFS and XGrid frustration

After upgrading some of our Xgrid agents to Leopard, using the /etc/exports method I was still unable to use NFS from within an Xgrid job. Some very odd permission behavior allowed jobs to touch files in the agent's working directory but they couldn't copy or read from NFS. Jobs which ran on Leopard Xgrid agents acted almost like they had been chroot'd. The same jobs had run previously on Leopard. Within a job I was unable to change to parent directories even though permissions were set appropriately. After a lot of head scratching I came across some talk on the xgrid-list and this blog post about sandbox, a policy enforcement framework in Leopard..

http://codm.genhex.org/index.php/2007/10/29/macosx-leopard-sandbox-seatbel/

Low and behold, /usr/share/sandbox has all kinds of new policy configurations, conveniently undocumented. I edited one line of /usr/share/sandbox/xgridagentd_task_nobody.sb to allow read/write to /nfs

(allow file-read* file-write* (regex "^/(private/)?(tmp|nfs|var)(/|$)"))

After that things appear to be back to normal. Documentation has to be one of my major headaches as a scientist using OS X. Hopefully posting here might help someone with a similar configuration.

Edit: it looks like I should've read the Leopard articles Charles wrote more closely as he addressed the sandbox issue here.

http://www.macresearch.org/xgrid-leopard-good-bad-ugly-and-new-stuff

Do I need to mount again after rebooting?

Thanks for this post -- I'm using this all the time to have other computers run XPLOR-NIH and store the results directly on my laptop's hard disk now.

It seems that I have to re-issue the mount command after rebooting the computer on which my laptop's disk is mounted via NFS. Can I make the mount permanent somehow?

EDIT: Never mind. It appears that wgscott has already discussed this here.