Okay, I’m going just about insane here.

Trying to set up an OS X (10.8.2) NFS client to connect to Debian (6.0.6) nfs server. I’ve mostly been following instructions here: https://help.ubuntu.com/community/NFSv4Howto which are very thorough. However, two issues:

  • When I don’t use Kerberos, the performance sucks (I think something must be timing-out), and all the files are apparently owned by nobody:nobody. Doing an ls of the mounted directory takes tens of seconds.
  • When I do try to use Kerberos, with a principal created for the server and for the client, I cannot mount the share. The client complains: mount_nfs: can't mount /mnt from servername.domain onto /home: Permission denied

I’ve set up two principals, nfs/servername@REALM and nfs/clientname@REALM, and copied into /etc/krb5.keytab on client and server.

The server is (according to Kerberos logs) getting tickets for nfs/servername.REALM so my suspicion is that the OS X NFS client isn't using its principal somehow.

Any ideas?

Update: /var/log/daemon.log reports:

Oct  7 19:12:43 servername rpc.svcgssd[19635]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): Unspecified GSS failure.  Minor code may provide more information - No supported encryption types (config file error?)

As per this page: http://permalink.gmane.org/gmane.comp.encryption.kerberos.heimdal.general/5551 I’ve removed all but the DES encryption options in both client and server krb5.keytab files. And added allow_weak_crypto in the /etc/krb5.conf file. And restarted hfs-kernel-server and it still doesn’t work. Sigh.

Actually, now it reports:

Oct  7 19:26:55 servername rpc.svcgssd[19721]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): Unspecified GSS failure.  Minor code may provide more information - Wrong principal in request

Does that “Wrong principal in request” mean that the client is passing the wrong krb5 principal? Can I control that in OS X?


NFSv4 seems to be fairly broken under Mac OS X 10.8.
The unofficial word is that Apple is aware of the issue but doesn't have a timeline for fixing it. Meanwhile, the consensus is that opendirectoryd is quite broken.

A few places that you might check for better debugging info:

  1. # sysctl -w vfs.generic.nfs.client.idmap_ctrl=127
    Watch the output of /var/log/system.log while your are trying to run the ls command.

  2. # odutil set log debug
    Watch the output of /var/log/opendirectoryd.log

  3. Use dtrace to figure out where the hangup is.
    Our experience has been that nfs4_id2guid is timing out because opendirectoryd isn't always registering itself properly with the kernel.


I thing you should try to create two others principals with your domain name added to your server name.

Like nfs/mysername.example.com@REALM and host/myclientname.example.com@REALM

But anyway, on MacOSX You have to have a TGT BEFORE trying to mount.

So before the mount try a kinit (any principal is ok).

Personnaly, I manage to have an nfs+kerberos on MacOSX. But in NFSV3.

In NFSV4 I manage to mount it, but it's slow... very slow.

  • These details are difficult to follow. Can you add some more specific info as to how you were able to setup the NFS client on MacOSX? – slm Jan 26 '13 at 12:10
  • What are you trying to do ? Because create an NFS client on Mac OSX is a very simple job : go -> connect... -> nfs://servername/. But if you want create the server + client + kerberos ... this is another job. – user156187 Jan 26 '13 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.