Red Hat Bugzilla – Bug 118922
(NFS)nfs client caches file handle improperly
Last modified: 2007-11-30 17:10:38 EST
Description of problem:
using FC1 as an NFS client (RHEL 3.0 NFS server) has problems with
'Stale NFS Handle' errors, which appear to be caused be the client
attempting to reuse a filehandle that is no longer valid.
more info below.
Version-Release number of selected component (if applicable):
FC1, all up-to-date as of 3/22/04. kernel 2.4.22-1.2174.nptl
bug does NOT occur when client is RHL 9.0 or RHEL 3.0
Steps to Reproduce:
1. ssh -X myserver date (exits after printing date)
2. xauth list (very soon after step 1, I believe within 1 second)
3. xauth list (as many times as you want. things are now buggered)
/usr/X11R6/bin/xauth: error in locking authority file
note: local home directory, and home directory on 'myserver' are nfs
mounted from same nfs server.
ultimately, what happens is that the first step causes a 'xauth list'
on the client (i.e. at least an NFS lookup on .Xauthority file) then
an 'xauth add' and 'xauth remove' on 'myserver'. it is the latter
that triggers the bug, because 'xauth remove' (use 'strace -f -o out
sshd -e -d -p <someport>' on myserver to catch this) ends up creating
a new .Xauthority file (i.e. creates new file, unlinks .Xauthority,
and renames new file to .Xauthority, the end result being that the
inode of .Xauthority changes).
now when step 2 is run, 'xauth list' attempts to open .Xauthority
again, but the NFS client uses the stale (cached) nfs file handle
(BUG), and so 'xauth list' receives 'Stale File Handle' error visible
to user space.
xauth list then exits, having already created .Xauthority-c and
the third step, xauth list again sees the lockfiles and exits with the
isn't there some rule about close-to-open consistency?
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/