Solution

Although the symptoms of ubuntu bug 1466654 look a lot like ours, it is not the cause.

The culprit is quite likely[1] our odd configuration of the non-kerberized NFS4 server (it has a keytab and a krb5.conf, but the keytab contains the wrong keys and the config is broken; no *gssd service is running), along with Red Hat bug 1334510:

If /etc/krb5.keytab exists, the NFS server assumes gssd will be running. The client then tries to fetch Kerberos-credentials, even if the share requires only sec=sys. Of course, the client won't be able to obtain such credentials if the principal doesn't even exist.

Procedure 1.  Two solutions exist beyond the one in the bugreport
  1. If the NFS4 server serves only non-kerberized shares, we can remove /etc/krb5.keytab and /etc/krb5.conf completely.

  2. Alternatively, we can give it a Kerberos keytab and a working krb5.conf anyway. The client then will retrieve tickets for the server principal, even though ultimately it'll never use them.

If the server serves some shares kerberized and some unkerberized, it needs to have a valid Kerberos keytab and config anyway, and the problem will not occur.



[1] even though this bug is reported for kernel 3.10