Re: 2.6 nfsd troubles - stale filehandles

[Fredrik Tolf]

Neil Brown writes:
 > On Wednesday December 3, fredrik@xxxxxxxxxxxxx wrote:
 > > 
 > > So, I managed to do it now. The strange thing is, I had created an
 > > extra share of the home dirs for this test (I had "mount --bind"'ed it
 > > on /var/lib/nfs/nfstest), and only set subtree_check back on the test
 > > export, in an attempt to keep the normal parts of the system reliable
 > > while testing, but just doing that made the real export behave bad as
 > > well. It seems to run amok as soon as I have subtree_checking on only
 > > one export.
 > 
 > "mount --bind" certainly has a good chance of confusing nfsd.
 > If you --bind mount the root of the filesystem somewhere else and
 > export that, then the filehandles generated will be exactly the same
 > and nfsd cannot know whether a request is indented for one mountpoint
 > or the other.
 > When using --bind, it is best to give an 'fsid=' option in
 > /etc/exports so that nfsd can use that to differentiate the mount
 > points.

Oh, I see. Now that you mention it, it does quite much make sense, I
have to admit.

 > > 
 > > nfsd_dispatch: vers 3 proc 1 
 > > nfsd: GETATTR(3)  36: 06000001 0000fe00 00000002 00023b44 00023957 00000000 
 > > nfsd: fh_verify(36: 06000001 0000fe00 00000002 00023b44 00023957 00000000) 
 > > nfsd_acceptable failed at c669a5c0 dc 
 > 
 > This strongly suggests that nfsd thought that the user making the
 > request didn't have 'x' access to the parent of 'dc'. i.e. to /hannes.

That's what I thought too, but I could not figure out why.

 > > 
 > > Some more info: I was root while causing this error, and the dir arch
 > > looks like this (from this filesystem's point of view, it is really my
 > > home dirs):
 > > 
 > > rwxr-xr-x  root   root  /
 > > rwx--x---+ hannes users /hannes
 > > rwxr-xr-x  hannes users /hannes/dc
 > 
 > And if you are not exporting with no_root_squash, then the user does
 > not have 'x' access to hannes.
 > 
 > So if you haven't exported with 'no_root_squash', then this completely
 > makes sense. The nfs client is allowing root access (based on cached
 > data that some other local users recently accessed) but the server is
 > not allowing root access. 
 > Arguably you should be getting "permission denied" rather than
 > "stale", but you certainly shouldn't expect it to work.
 >
 > If, on the other hand, you have specified no_root_squash, then this is
 > still very strange.
 > 
 > What export options are you using?

I'm sorry for not clarifying that immediately. The entire export line
goes like this:

/home 192.168.0.0/16(sync,rw,no_root_squash,subtree_check)

So as you can see, I am indeed using no_root_squash, which is exactly
why I thought it was so strange. I did take a look at nfsd_acceptable,
and I just couldn't understand it (I understood the code, but I
couldn't understand how it could fail).

FYI, I'm currently using ReiserFS with ACL patches on this filesystem,
but before that I was using ReiserFS without ACL, and before that I
was using XFS, and these errors have been there all the time. At first
I thought the errors were because of XFS, and therefore I switched to
ReiserFS, but that didn't stop it from happening.

Fredrik Tolf

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/