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
lsof 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/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.
Oct 7 19:12:43 servername rpc.svcgssd: 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: 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?