Even if the kerberos use flag for nfs-utils (v4) is set to off, the nfs client init scripts ignore the setting and try to load it * Starting gssd ... /etc/init.d/rpc.gssd: line 20: /usr/sbin/rpc.gssd: No such file or direc [ !! ] * Starting svcgssd ... /etc/init.d/rpc.gssd: line 20: /usr/sbin/rpc.svcgssd: No such file or di [ !! ] Thus, it appears that the kerberos use flag must be on and everything else needed to use kerberos for nfs be setup in order for the nfs client v4 to work at all.
Well, I'm no expert on this, but to me it looks like the kerberos stuff is required for the nfs4 protocol and optional for lower versions.
A new security flavor called RPCSEC_GSS, has been added, but it's optional, not required. Kerberos is one way to implement it, but it's entirely separate from the default security flavor, which doesn't require RPCSEC_GSS.
nfs4 security features are not mandatory (krb5, spkmv3), as it can be seen on ubuntu and debian, rpc.gssd should only be started if you have a mention of GSS secured mounts in your fstab.
Created attachment 127898 [details, diff] nfsmount.patch this patch against nfsmount init script makes it start rpc.gssd only if there is mention of a krb5 secured mount in fstab. It matches the current behavior of debian's init script and should apply on nfs init script as well.
just read bug #186037, I'll need to update this patch to allow nfsv3+krb5 it seems.
nfs-utils-1.0.12-r4 only forces kerb stuff when options contains 'sec=krb'
err, make that 1.1.0-r1
