I have two systems on a local network, nfsclient (CentOS 7) and nfsserver (CentOS 6). These names correctly resolve to their IP addresses, and Kerberos is working between them (nfsserver is the KDC). I have a Kerberized NFSv4 share exported on nfsserver; my /etc/exports is as follows:
/export *(rw,sync,fsid=0,no_subtree_check,sec=krb5p)
/export/home *(rw,sync,no_subtree_check,no_root_squash,sec=krb5p)
I can see these exports from nfsclient:
[root@nfsclient ~]# showmount -e nfsserver
Export list for nfsserver:
/export/home *
/export *
If I remove the sec=krb5p options in /etc/exports, I can mount the share from nfsclient using
[root@nfsclient ~]# mount -t nfs4 nfsserver:/ /mnt/nfs
When NFS is Kerberized, however, things don't go as well:
[root@nfsclient ~]# mount -t nfs4 -o sec=krb5p nfsserver:/ /mnt/nfs
mount.nfs4: access denied by server while mounting nfsserver:/
This is accompanied by a series of repeated error messages in /var/log/messages:
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Nothing shows up in the logs on the server. Running klist on the client shows that root has a credentials cache at /tmp/krb5cc_0, so I'm led to think there's a problem with gss-proxy.
/etc/gssproxy/gssproxy.conf:
[gssproxy]
[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/gssproxy/http.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = 48
[service/nfs-server]
mechs = krb5
socket = /run/gssproxy.sock
cred_store = keytab:/etc/krb5.keytab
trusted = yes
kernel_nfsd = yes
euid = 0
[service/nfs-client]
mechs = krb5
cred_store = keytab:/etc/krb5.keytab
cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
cred_usage = initiate
allow_any_uid = yes
trusted = yes
euid = 0
So gss-proxy must be looking for the credentials cache in /var/lib/gssproxy/clients. It's also getting keys from /etc/krb5.keytab (which has keys for the principals nfs/nfsclient and host/nfsclient). However, /var/lib/gssproxy/clients seems to always be empty on nfsclient.
Am I missing something here? I can't figure out what exactly is going wrong with mounting this share.
/etc/sssd
configuration to see if SSSD is being used for credentials caching. access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…