|Summary:||NFS4 Kerberos : Impossible to mount if sec=krb5* is passed.|
|Product:||Red Hat Enterprise Linux 4||Reporter:||Jose Plans <jplans>|
|Component:||kernel||Assignee:||Jeff Layton <jlayton>|
|Status:||CLOSED DUPLICATE||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-03-22 16:18:43 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Jose Plans 2007-02-26 14:26:38 UTC
Description of problem: Trying to mount NFS4 with options krb5,krb5p,krb5i fail on RHEL4 with the latest packages installed. Without the sec option, the mount happens correctly. The errors we have : -- kernel: gss_create: Pseudoflavor 390005 not found!<6>RPC: Couldn't create auth handle (flavor 390005) kernel: NFS: cannot create RPC client." -- Or: -- $mount -t nfs4 -osec=krb5 -vvvv 192.168.250.130:/ /mnt/nfsv4/ Warning: rpc.gssd appears not to be running. mount: pinging: prog 100003 vers 4 prot tcp port 2049 mount: Cannot allocate memory -- Or; -- client rpc.gssd: WARNING: Failed to create krb5 context for user with uid 0 for server nfs-server.sagueb.com client rpc.gssd: WARNING: Failed to create krb5 context for user with uid 0 with credentials cache FILE:/tmp/krb5cc_machine_SAGUEB.COM for server nfs-server.sagueb.com client rpc.gssd: WARNING: Failed to create krb5 context for user with uid 0 with any credentials cache for server nfs-server.sagueb.com client rpc.gssd: doing error downcall -- Now, the keytabs on both server and clients include nfs,host principals. If we perform klist on the server : -- Ticket cache: FILE:/tmp/krb5cc_0 Default principal: root/admin@SAGUEB.COM Valid starting Expires Service principal 11/01/06 16:01:41 11/02/06 16:01:41 krbtgt/SAGUEB.COM@SAGUEB.COM 11/02/06 11:10:32 11/02/06 16:01:41 nfs/client.sagueb.com@SAGUEB.COM 11/02/06 11:10:38 11/02/06 16:01:41 nfs/nfs-server.sagueb.com@SAGUEB.COM -- Basically we cannot mount the share, and we are quite stucked. Version-Release number of selected component (if applicable): nfs-utils : nfs-utils/1.0.6/77.EL4 kernel: 2.6.9-42.0.8.EL How reproducible: Always. Steps to Reproduce: 1. Setup KDC and krb5.conf to get keytabs containing : nfs/ host/ 2. Export the keytab to the client. 3. Setup the NFS server. 4. Mount the NFS share with -o sec=krb5 Actual results: Different error messages. No mount. Expected results: Clean mount. Additional info: Customer solved/workarounded this by adding into /etc/passwd : -- nfs/nfsclient.dns:x:99:99::::, -- Please let me know if anything is missing or you need any further information, It might be a configuration issue, if so what is missing ? The configuration has been based on : http://wiki.linux-nfs.org/index.php/Nfsv4_configuration
Comment 2 Steve Dickson 2007-03-22 13:39:52 UTC
Try adding [domain_realm] server.domainname.com = SAGUEB.COM to your krb.conf file
Comment 3 Jeff Layton 2007-03-22 13:43:16 UTC
Contrary to the docs, krb5p is not present in RHEL4's kernel. That wasn't added until well after 2.6.9 was released upstream.
Comment 4 Jeff Layton 2007-03-22 13:56:00 UTC
...sorry, hit commit button too soon. So the lack of krb5p is, I think, what accounts for the first error message he describes: -- kernel: gss_create: Pseudoflavor 390005 not found!<6>RPC: Couldn't create auth handle (flavor 390005) kernel: NFS: cannot create RPC client." -- On the other problems...the fact that this strangeness worked around the problem sounds like he has something strange with his hostname resolution: nfs/nfsclient.dns:x:99:99:::: First, he's using "short" hostnames: $ cat hostname client ...these need to be fully-qualified. Also, he needs to make sure that when he reverse resolves the ip addresses, that they resolve to FQDN's as well. Please have him change this and then try it again. Steve's suggestion would also be good, but I'm thinking that his krb5.conf is probably set up correctly already and that he just needs to fix up his hostnames and hostname resolution. Please have him do that and try it again.
Comment 8 Steve Dickson 2007-03-22 14:57:55 UTC
Make sure the HOSTNAME variable in /etc/sysconfig/network is set to the FQDN...
Comment 10 Jeff Layton 2007-03-22 16:18:43 UTC
Closing this case as a dupe of 189900 since that seems to have been the only bug in play after the hostnames were fixed. *** This bug has been marked as a duplicate of 189900 ***