2

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.

  • Worth highlighting that the NFS-Server is running CentOS 6, while NFS-Client is CentOS 7. Additionally, it would help if the specific minor versions of the OSs were provided as well as the specific versions of the packages installed/used on both servers. Also, how the overall configuration was done; i.e.. using FreeIPA_/_IdM or not. Lastly, what happens if the sub-folder is mounted? As a result, additional, different errors might be displayed and provide helpful hints to the root cause of the failures. – ILMostro_7 Aug 26 '17 at 11:02
  • You can also check your /etc/sssd configuration to see if SSSD is being used for credentials caching. access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/… – ILMostro_7 Aug 26 '17 at 11:15
1

There is an issue with the default file config in defining the path of the cache. Try with this configuration of the client, in /etc/gssproxy/gssproxy.conf:

[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/tmp/krb5cc_%U
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0
  debug = true
0

make sure your client is joined to the domain.

ipa-client-install --force-join

Then ensure you have a ticket

kinit admin

and then double check the krb5.keytab

restorecon -v /etc/krb5.keytab

ensure your client is in the keytab

kinit -k

host/ < client > . < domain > @REALM

You should then be able to mount with sec=krb5p

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.