Debian – Setting up a Mac Mountain Lion NFS client to securely access Debian NFS server

debiankerberosmac-osxnfs

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?

Best Answer

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.

Related Topic