+++ This bug was initially created as a clone of Bug #218720 +++
Verified the bug on RHEL 5 Beta 2.
Description of problem:
I have a working kerberized NFS4 setup. Server is RHEL 4 with updated packages:
I regularly access this from another RHEL 4 box with similarly updated packages.
I'm trying to access it from FC6.
I mount the fs with:
mount -t nfs4 -o sec=krb5,fstype=nfs4,hard,intr gideon.revolutionwall.net:/ /mnt/
This succeeds. As a regular user, I kinit and try to access the mount:
[mbooth@mbooth ~]$ ls -l /mnt
ls: /mnt/photos: No such file or directory
ls: /mnt/video: No such file or directory
drwxrwsr-x 157 root vol 8192 Nov 30 19:41 photos
drwxrws--- 7 root vol 4096 Oct 23 22:22 video
I see the following in /var/log/messages:
net/sunrpc/rpc_pipe.c: rpc_lookup_parent failed t
o find path /nfs/clnt11/krb5
If I run rpc.gssd on the client manually with -f -vvvvvvvrrrrrrrrr, on mount I
also see the error message:
Warning: rpc.gssd appears not to be running.
If I start rpcgssd with service rpcgssd start, I do not see this message.
Nevertheless, in both cases it is most certainly running.
SELinux is completely disabled.
Version-Release number of selected component (if applicable):
José Plans did some debugging on this. I did the following:
echo 65535 > /proc/sys/sunrpc/nfs_debug
echo 32767 > /proc/sys/sunrpc/rpc_debug
and tried to access the mount again. There was a great deal of output, but José
mentioned the following as being particularly significant:
Dec 14 10:41:24 mbooth kernel: RPC: creating GSS authenticator for client
Dec 14 10:41:24 mbooth kernel: net/sunrpc/rpc_pipe.c: rpc_lookup_parent failed
to find path /nfs/clnt4/krb5
Dec 14 10:41:24 mbooth kernel: nfs_init_server_rpcclient: couldn't create credcache!
There is a know problem with the RHEL4 svcgssd daemon... please
try RHEL5 to RHEL5... something I was able to get working...
Note that although the server is mostly RHEL 4, I upgraded everything nfs and
kerberos related to get this working. nfs-utils on the server is
nfs-utils-1.0.9-5. On my RHEL 5 laptop it's nfs-utils-1.0.9-10. Also note that
this is a working configuration. I access this server regularly.
José Plans suggested this might be related to available ciphers in the kernel.
Is that a possibility?
Unfortunately I don't have spare hardware to test a RHEL5 server.
yes... the only cipher that is supported is DES... so can I close this bug?
Not really, as this would be a regression. I'm still using a standard RHEL 4 kernel.
This should be fixed in nfs-utils-1.0.6-76
nfs-utils on the RHEL 4 server is nfs-utils-1.0.9-5. nfs-utils on the RHEL 5
client is nfs-utils-1.0.9-10.el5.i386. These are both higher than
Is it nfs-utils or the kernel which doesn't support the required ciphers?
oops... Please disreguard Comment #7 since nfs-utils-1.0.6-76 is the rhel4
which does fix a problem with secure mounts...
> nfs-utils on the RHEL 4 server is nfs-utils-1.0.9-5....
no... that more of a early RHEL5 or FC-6 version...
Note, using nfs-utils-1.0.6-76 on the RHEL4 and nfs-utils-1.0.9-16.el5
on the RHEL5 side, I was able to get secure mounts working...
I'm going close this since I am able to get secure mounts working
in the latest RHEL5 update.