Home / server / Questions / 435716
In Process
andrewf
Asked: 2012-10-08 10:01:49 +0800 CST

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

  • 772

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?

debian

2 Answers

  1. 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.

    • 3

  2. 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.

    • 0