You are not logged in.
Hi!
While trying to find a solution for this problem, I found something else wrong with my NFS configuration, but I can't quite understand what's going on. I enabled the rpc-gssd service on the client machine as advised by the wiki page, however, after a successful mount of the NFS share I get the following errors on the client:
systemd[1]: Started RPC GSS-API client-side daemon.
rpc.gssd[14675]: ERROR: Key table file '/etc/krb5.keytab' not found while beginning keytab scan for keytab 'FILE:/etc/krb5.keytab'
rpc.gssd[14675]: ERROR: Key table file '/etc/krb5.keytab' not found while beginning keytab scan for keytab 'FILE:/etc/krb5.keytab'
rpc.gssd[14675]: ERROR: Key table file '/etc/krb5.keytab' not found while beginning keytab scan for keytab 'FILE:/etc/krb5.keytab'
rpc.gssd[14675]: ERROR: Key table file '/etc/krb5.keytab' not found while beginning keytab scan for keytab 'FILE:/etc/krb5.keytab'
rpc.gssd[14675]: ERROR: Key table file '/etc/krb5.keytab' not found while beginning keytab scan for keytab 'FILE:/etc/krb5.keytab'
rpc.gssd[14675]: ERROR: Key table file '/etc/krb5.keytab' not found while beginning keytab scan for keytab 'FILE:/etc/krb5.keytab'
rpc.gssd[14675]: ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host htpc
rpc.gssd[14675]: ERROR: No credentials found for connection to server htpc
However, I never configured the NFS mount to use Kerberos, at least not willingly! I tried to mount with the "sec=sys" option, but same result, even if that security option should disable kerberos. What is even more strange is that another Archlinux (ARM) machine connecting to the same share doesn't show any such error on the rpc-gssd service. I tried to check the config files for differences, but they really look the same. Actually they are exactly the default versions provided with the packages, as I didn't modify any of them.
Any help here would be really appreciated! Thanks!
Offline
That is the expected result when you enable the client for a daemon that isn't running. In reality this is just a workaround for the nfs4 mount delay we have been experiencing, and should not by any means be considered a solution.
Offline
I see, thanks. Is the mount delay an Arch-specific problem? What are the causes, exactly?
Offline
I don't know enough about nfs4, kerberos, or any of that to tell you why this happens. But from a bit of searching for an answer in the past couple months, it seems as though other distributions face this issue as well.
Offline