Red Hat Bugzilla – Bug 201438
vi (chown) doesn't work in an nfs4 mount
Last modified: 2007-11-16 20:14:53 EST
Running vi in a nfs4 home directory gets stuck in a call to chown
strace shows that the chown call never returns.
chown("5159", 1111, 222) = ? ERESTARTSYS (To be restarted)
the ERESTARTSYS is because of a kill.
The server is a x86_64 RHEL4 machine and both i386/x86_64 RHEL4 clients
have the problem with nfs4 mounts with sec=sys and sec=krb5. A mount from
a FC5 client to the same server works fine.
The RHEL4 machines are fully patched (U3+fasttrack) and the latest available
kernel (2.6.9-42.ELsmp) doesn't help either.
Let me know if you want tcpdump logs etc.
Still there in update4
I'm not seen this behavior at all... so could you please posted
as bzip2 binary tethereal trace of the problem. Something
similar to 'tethereal -w /tmp/data.pcap host <server> ; bzip2 /tmp/data.pcap'
Hmm this is going to take a while, it seems that the machine is hit by something
similar to: http://linux-nfs.org/pipermail/nfsv4/2006-April/004132.html and
Since the new nfs-utils-lib includes librpcsecgss-0.10 I suspect that this is
I'll roll back to the older version of nfs_utils* to get the network dump.
Do you want me to open a new bug for the "rpc.gssd: WARNING: can't create
rpc_clnt for server ...." error message?
Yes.. please... thanks!!
Created attachment 134314 [details]
nfs4 network trace with host servername and port 2049
I had to roll back the server (x86_64 also) as well since it was failing with:
Aug 16 15:33:23 icva rpc.svcgssd: WARNING: get_uid failed
Aug 16 15:33:23 icva rpc.svcgssd: WARNING: handle_nullreq: get_uid failed
Aug 16 15:33:48 icva rpc.svcgssd: WARNING: get_uid failed
Aug 16 15:33:48 icva rpc.svcgssd: WARNING: handle_nullreq: get_uid failed
Aug 16 15:34:13 icva rpc.svcgssd: WARNING: get_uid failed
Aug 16 15:34:13 icva rpc.svcgssd: WARNING: handle_nullreq: get_uid failed
Which makes me wonder how did I manage to claim that the chown bug is still
there in update4? Probably I only tested with the new kernel...
#203239 for the regression.
Any thoughts on what is causing the problem? Can you replicate the problem at all?
This probably does not happen when you don't use sec=krb5, correct?
Both sec=sys and sec=krb5 show the problem, the server is x86_64 but I tried
both i386 and x86_64 clients (with and without krb5).
When does the server reply with NFS4ERR_DELAY? From what I can see the client
keep sgetting the delay "error" forever :(
Well when the server returns NFS4ERR_DELAY, it generally means
the server has done an upcall to some user daemon and is waiting
for the response (i.e. a downcall)..... Now a NFS4ERR_DELAY on
the client means go away for a second or two and then retry...
So seeing the client continuously trying is normal....
Now looking a Comment #7, it appears the user level
daemon the server is waiting for is rpc.svcgssd, who seems
to be having a problem getting the uid from Kerberos...
What version of nfs-utils and nfs-utils-lib are you using?
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
The testing was done with the version previous to 4.4, since the latest version
is broken under x86-64.
The error message in comment #7 is from nfs-utils-1.0.6-70.EL4 (bugzilla
#203239) which is a different issue.
Just curious... what is the containts of /etc/gssapi_mech.conf?
It should have an entry like:
I think I did remove the /usr/lib/ by hand since the install was before the fix
(was it in 4.4? I can't remember really)
The errors in Comment #7 should be fixed in nfs-utils-1.0.6-76
Is nfs-utils-1.0.6-76 available anywhere? I imagine it's part of 4.5 right?
yes... Please feel free to reopen this bug if you still have the same