Messages in this thread | | | From | Fredrik Tolf <> | Date | Thu, 4 Dec 2003 04:31:00 +0100 | Subject | Re: 2.6 nfsd troubles - stale filehandles |
| |
Neil Brown writes: > On Wednesday December 3, fredrik@dolda2000.com 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |