NFSv4: rpc.gssd hangs indefinitely
Hi,
Any NFSv4 experts on this list? I'm trying to get my fileserver to
incorporate Kerberos security but the mounts fail in the most annoying
way: no error or syslog message, not even a timeout. They just hang.
I've already spent a few hours trying to set it up and debug it, and I
believe I've managed to avoid the usual pitfalls this time around
(principals, keytabs, encryption types, exports). The Kerberos/LDAP
setup itself is not an issue, and non-Kerberized nfs4 mounts work
perfectly -- that is the setup that I've been running for the past year.
So, for those of you who are still listening, here is the problem in
short (server is running Squeeze):
ladmin@genie:~$ sudo mount -v -t nfs4 genie:/ /mnt
mount.nfs4: timeout set for Mon Oct 17 01:32:18 2011
mount.nfs4: trying text-based options
'addr=172.22.21.8,clientaddr=172.22.21.8'
genie:/ on /mnt type nfs4 (rw)
ladmin@genie:~$ sudo mount -v -t nfs4 -o sec=krb5 genie:/ /mnt
mount.nfs4: timeout set for Mon Oct 17 01:32:35 2011
mount.nfs4: trying text-based options
'sec=krb5,addr=172.22.21.8,clientaddr=172.22.21.8'
... and the command prompt never returns. Adding -vvv to the mount
command doesn't reveal anything new, and enabling -vvv on all the
daemons gives the following (among the many interesting lines):
Oct 17 00:39:04 genie rpc.gssd[16110]: Success getting keytab entry for
'nfs/genie.loos.site@'
Oct 17 00:39:04 genie rpc.gssd[16110]: creating context with server
nfs@genie.loos.site
Oct 17 00:39:04 genie rpc.svcgssd[15500]: prepare_krb5_rfc1964_buffer:
serializing keys with enctype 4 and length 8
Oct 17 00:39:04 genie rpc.svcgssd[15500]: doing downcall
Oct 17 00:39:04 genie rpc.svcgssd[15500]: finished handling null request
Oct 17 00:39:04 genie rpc.gssd[16110]: prepare_krb5_rfc1964_buffer:
serializing keys with enctype 4 and length
8 Oct 17 00:39:04 genie rpc.gssd[16110]: doing downcall
And there my google-fu ends. Comparing other logs, the downcall here
should result in calls to idmapd. But the id mapper is working fine, as
it's also needed for the non-krb5 case. The idmapd logs show a
deafening silence... until the mount command is killed, in which case I
get "stale client" in the idmapd logs.
I'm not willing to file a bug yet, I wouldn't know what package to
report it on. Moreover, the last two times that I've reported a bug, I
found a solution within five minutes of sending. So here's hoping... :)
Any pointers/hints/tips are greatly appreciated.
Thanks,
Arno
Reply to: