4

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?

andrewf
  • 271
  • 1
  • 3
  • 8

2 Answers2

3

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.

voretaq7
  • 79,345
  • 17
  • 128
  • 213
Mathew Eis
  • 31
  • 2
0

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.

slm
  • 7,355
  • 16
  • 54
  • 72
user156187
  • 1
  • 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