sec=krb5 mounts never return

[Arno Schuring <aelschuring@hotmail.com>]

Hello list,

tl;dr: mount calls with sec=krb5 never return. They appear to get
stalled in the kernel on "svc: transport is dead". I need to know
if this is a configuration issue, a kernel problem or a userland
problem, and how it can be resolved.


I've been running a succesful NFS4 setup at home for a year now, but
incorporating krb5 security has so far proven fruitless. I believe the
Kerberos side of the equation is no longer causing problems; it is used
for user authentication too, and nfs security contexts seem to work
properly. As said above, the mount request for any Kerberos mount gets
halted somewhere in flight:

# mount -vvv -t nfs4 -o sec=krb5 genie:/media /mnt
mount: fstab path: "/etc/fstab"
mount: mtab path:  "/etc/mtab"
mount: lock path:  "/etc/mtab~"
mount: temp path:  "/etc/mtab.tmp"
mount: UID:        0
mount: eUID:       0
mount: spec:  "genie:/media"
mount: node:  "/mnt"
mount: types: "nfs4"
mount: opts:  "sec=krb5"
mount: external mount: argv[0] = "/sbin/mount.nfs4"
mount: external mount: argv[1] = "genie:/media"
mount: external mount: argv[2] = "/mnt"
mount: external mount: argv[3] = "-v"
mount: external mount: argv[4] = "-o"
mount: external mount: argv[5] = "rw,sec=krb5"
mount.nfs4: timeout set for Sun Oct 16 22:52:10 2011
mount.nfs4: trying text-based options
'sec=krb5,addr=172.22.21.8,clientaddr=172.22.21.5'

And there it just seems to hang (the timeout is ignored completely)
until killed via signal or Ctrl-C. The same mount without sec=krb5
completes without issue:
# mount -v -t nfs4 genie:/media /mnt
mount.nfs4: timeout set for Thu Oct 20 23:48:55 2011
mount.nfs4: trying text-based options
'addr=172.22.21.8,clientaddr=172.22.21.8'
genie:/media on /mnt type nfs4 (rw)

The machine is running a fully updated Debian 6.0 (Squeeze). So far I
have only tried with one other client (also Squeeze) with similar
results. Relevant software versions: kernel 2.6.32 (armel) and
nfs-utils 1.2.2.


The only suggestion that Google has been able to give me was to verify
that the rpcsec_gss_krb5 was loaded, and it is:
$ lsmod|grep gss
rpcsec_gss_krb5         9026  5 
auth_rpcgss            33334  4 rpcsec_gss_krb5,nfsd,nfs
sunrpc                171216  21 [..]

Reproducible with only these exports:
# exportfs -v
/srv/nfs  172.22.21.8(ro,wdelay,root_squash,no_subtree_check,fsid=0)
/srv/nfs  gss/krb5(ro,wdelay,root_squash,no_subtree_check,fsid=0)


I can provide a full rpc_debug/svc_debug log if required. I'm not
attaching it now because it is somewhat large (well, 60k) and I'm not
even sure that user issues are on-topic for this list. What looks
suspicious to me is the following excerpt:
[600472.772226] nfsd: connect from 172.22.21.8, port=46257
[600472.772300] svc: svc_setup_socket created deda1a00 (inet df948900)
[600473.431966] svc_recv: found XPT_CLOSE
[600473.431982] svc: svc_delete_xprt(deda1a00)
[600473.432114] svc: transport deda1a00 is dead, not enqueued



I'd be grateful for any pointers,
Arno
(not subscribed, please keep me in CC)