Setting up Kerberised NFSv4 client on Mac OS X

Click to select OS Version (selected version highlighted):

My Environment

  • NFS Server: (Solaris 10 – specifically 5.11, NexentaOS_20090926)
  • KDC Server: (ie same box)
  • Domain name:
  • Client: Apple OS X Leopard (10.5.8)

Problem to be solved

  • a) Mount directory tree from Solaris onto one or more Macs such that files owned by kim (uid=1000, gid=10) on the NFS server may be read/written as expected by user kim on the Mac (uid=501, gid=20).
  • b) “ls -l” should always show the correct ownerships (ie show up as owned by “kim”) even though kim has different uids on client and server.

Before continuing I suggest you read NFSv4 on Apple OS X.

Method 1) Really simple but not perfect

As it stands (maybe can be configured) it doesn’t quite address superficial problem b). See caveat at end.

1a) Setting up Apple Kerberos Application on Tiger and Leopard

1b) Mounting the Share
  • Finder -> Go -> Connect to Server
    • Enter: nfs: //
    • Connect

1c) Check it works
  • You will see that nfs/ ticket appear in the Kerberos application.

With a bit of luck you should shortly find yourself able to access your remote filing system with full permissions.

Note: I actually used the IP address of my NFS server as I had DNS problems prior to Kerberos.
Note: In case it is not ticked, I suggest selecting: Finder -> Preferences -> General -> Connected Servers (shown on Desktop)

Having done all this – it DOES work for me BUT original problem b) is not solved. In a console window the mounted filing system /Volumes/XXXX/…. shows the Server uid/gid mapped (where valid) to local mac user/group names (or left numeric where no mapping exists).
I can live with this but I intend fixing it.

Method 2) A bit more complex but addresses all problems.

Before continuing I suggest you read NFSv4 on Apple OS X, including the section newnfs limitations. Also read the HOWTO in the downloaded tarball.

2a) Download the newnfs source/binaries.

2b) Install newnfs
  • Review the HOWTO, Setup and Kerberos-Setup install instructions
  • Follow the HOWTO install instructions (ie up to “Starting nfsuserd by hand”).

2c) Running the daemon(s)
  • The HOWTO details getting the daemon(s) to run at startup. Initially however I suggest running them manually, and when it's working configure the autostartup.
  • You can carry on with the HOWTO but for reference this is what I did:
  • In one terminal window as root:
# cd /Library/Filesystems/ca.uoguelph.newnfs.fs/Support
# sync
# ./nfsuserd -kext -cbd -domain 1

2d) Setting up Apple Kerberos Application on Tiger and Leopard
This step can actually be done any time above, but we do it here just before we need a ticket.
2e) Configure the Kerberos Ticket encryption types

This step is not needed for Leopard as the defaults work for me, but following the Tiger instructions won't hurt and may be instructive (select Tiger view at top of page if desired).

2f) Testing the mount
  • Start the Kerberos application again and authentication if needed.
  • In a terminal window (running as NORMAL user - ie not root):
$ mkdir /mnt
$ chmod 777 /mnt       (just for convenience. Or could be chown kim:staff /mnt)
$ mount -t newnfs -o -4,-Skrb5  /mnt
$ cd /mnt
$ touch z

  • In Tiger code version -T (TCP) is required in the mount options whereas it is the default in the Leopard version.
  • The mount is done as a normal user not as root (to ensure the user's kerberos ticket is used)
  • -Skrb5 to -Skrb5i or -Skrb5p can be set as needed, but I suggest krb5 initially.
  • The very first time I did “touch z” it appeared to hang. I ctrl-C’d it and did it again and it worked. Maybe it was trying to get the nfs ticket.
  • Tuning rsize and wsize may improve NFS performance, but it should already be acceptable and adjustments may not be as appropriate on TCP where packet sizes are larger by default (I think).

2g) Check it works
  • You will see that nfs/blackhole tick appear in the Kerberos application.
  • In the terminal ls -l works correctly, so all the original requirements are met.
  • If you get an error like "Authentication error" when doing ls, one cause is mounting as root but accessing the mount point as a normal user (or vice versa). The user with the kerberos ticket should be doing the mounting.

The original document is available at