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:
- Output of rpc.gssd with the "-vvv" option enabled.
- Output of rpc.svcgssd with the "-vvv" option (if this is a Linux server).
- Output of "klist -e -k /etc/krb5.keytab" on the client and/or server.
- Contents of /etc/krb5.conf file on the client and/or server.
- 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
