Bug 118922 - (NFS)nfs client caches file handle improperly
(NFS)nfs client caches file handle improperly
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-03-22 15:38 EST by David Mansfield
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-29 16:14:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Mansfield 2004-03-22 15:38:59 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

How reproducible:

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)
Actual results:
/usr/X11R6/bin/xauth: error in locking authority file

Expected results:

Additional info:
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?
Comment 1 David Lawrence 2004-09-29 16:14:20 EDT
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/

Note You need to log in before you can comment on or make changes to this bug.