Projects: Linux NFSv4 Frequently Asked Questions Projects: Linux NFSv4 Frequently Asked Questions

FAQs about CITI's Linux NFSv4 Implemention

NFSv4 using AUTH_SYS

NFSv4 using AUTH_GSS (Kerberos 5)

1. My mount works with AUTH_SYS, but fails when using Kerberos 5 (-osec=krb5)?

There are many reasons this could be failing. First verify that rpc.gssd is running on the client and rpc.svcgssd is running on the server. Running these daemons with option "-vvv" will produce extra debugging output which may give more information about the problem.

What to look at next depends on the messages that you see...

Please send the following information if requesting help:

  1. Output of rpc.gssd with the "-vvv" option enabled.
  2. Output of rpc.svcgssd with the "-vvv" option (if this is a Linux server).
  3. Output of "klist -e -k /etc/krb5.keytab" on the client and/or server.
  4. Contents of /etc/krb5.conf file on the client and/or server.
  5. Output of the "ping -c 4 [server-hostname]" on the client machine. (This verifies connectivity and is also helpful to determine whether there is an DNS alias for the server machine.)

2. I have the same export mounted with both AUTH_SYS and AUTH_GSS. Why isn't the AUTH_GSS mount working as expected?

Both mount points are treated the same. The security of the one mounted first will be used. So mounting with AUTH_SYS and then AUTH_GSS will result in both using AUTH_SYS. Mounting with AUTH_GSS and then AUTH_SYS will result in both using AUTH_GSS.

3. I see the message " WARNING: unable to locate function krb5_gss_internal_release_oid in krb5 mechanism library: there will be problems if multiple mechanisms are used!"

This message can be safely ignored. It has been removed in newer versions of the gssapi mechanism glue code.

4. I see the message "failed to open /proc/net/rpc/auth.rpcsec.init/channel" when starting rpc.svcgssd

This message means that the rpcsec_gss code is not included in the kernel. Either the option wasn't selected or it was compiled as a module and the module hasn't been inserted into the kernel.

5. I am accessing an NFSv4 mount via Kerberos as root. Why isn't it using the credentials I got via kinit?

ALL accesses as root on a Linux client (uid=0) currently use the machine credentials, not any credentials obtained via kinit. We plan to change this behavior when moving to use the new key ring kernel support to store credentials and contexts.

6. I am accessing an NFSv4 mount via Kerberos and then I do a kdestroy, but I am still able to access the NFS data. Why?

The kernel code caches the gssapi context that was negotiated using the Kerberos credentials. Destroying the credentials does not destroy the context in the kernel. We plan to change this behavior when moving to use the new key ring kernel support to store credentials and contexts.

7. I keep hearing about this key ring support, when will it be ready?

We're working on it! The plan is to have it working ASAP.

8. When doing a mount with Kerberos I see the message "WARNING: Error from getaddrinfo for server 'nfsserver.domain.edu': Servname not supported for ai_socktype".

Check to see that you have the nfs service listed in your /etc/services file.

nfs             2049/tcp        nfsd            # Network File System
nfs             2049/udp        nfsd            # Network File System

9. I am using an Active Directory(Microsoft) KDC and am having problems mounting with Kerberos. Can you help?

The first thing to do is look at Mike Eisler's blog entry about this.

If your /etc/krb5.conf has "enctype" lines such at the following, they should be removed!. See this Microsoft Support entry for one reason why. In general, these lines should never be used unless there is a specific reason to use them.

        default_tkt_enctypes = des-cbc-md5; or des-cbc-crc
        default_tgs_enctypes = des-cbc-md5; or des-cbc-crc

NFSv4 using AUTH_GSS (SPKM-3)

1. Can I use SPKM-3 ?

The SPKM-3 support is still not complete. There is experimental kernel code, but more work is needed for the user-level library.

NFSv4 using AUTH_GSS (LIPKEY)

1. Can I use LIPKEY ?

LIPKEY depends on SPKM-3. When the SPKM-3 support is complete, (see above) it should not be much more effort to add LIPKEY support.

NFSv4 Name to ID mapping

1. How do I set up name-to-id mapping?

You can choose between the default nsswitch method, or use our experimental method described here.

2. How do I look at the name-to-id mappings cached in the kernel?

The following script (run as root) will list the mappings from the server's cache.

#!/bin/sh
echo "Name-id cached entries:"
cachedir=/proc/net/rpc/nfs4.idtoname
cat ${cachedir}/content

3. How do I flush the name-to-id mappings cached in the kernel?

The following script (run as root) will list and then flush the mappings from the server's cache. (There is currently no way to flush the client's mappings.)

#!/bin/sh
cachedir=/proc/net/rpc/nfs4.idtoname
echo "Flushing server name-id cache"
echo "Before:"
cat ${cachedir}/content
echo `date +'%s'` >${cachedir}/flush
echo "After:"
cat ${cachedir}/content