Re: V3 ACCESS call fails after server reboot

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Dec 10, 2007 at 06:20:04PM +0100, Frank van Maarseveen wrote:
> Tested on 2.6.22.10 and 2.6.23.9, client and server running same version.
> export options: rw,sync,no_root_squash,no_subtree_check,mp
> 
> After a substantial amount of time (days) but also after a server
> reboot a process loses access to its current working directory when
> access to a parent directory two (or more) levels up has been revoked:
> 
> 	$ cd /mnt
> 	$ mkdir -p a/b/c
> 	$ cd a/b/c
> 	$ chmod 0 ../..
> 	$ ls -a
> 	. ..
> 	$
> 		(wait a loong time or reboot server)
> 	$ ls -a
> 	ls: .: Permission denied
> 
> Network traffic capture showed a V3 ACCESS call for above "." failing
> on the server after the reboot with NFS3ERR_ACCES. It succeeded before.
> 
> I have the impression the server is internally rechecking the entire
> path when its caches have been flushed. This behavior is problematic
> for daemons which change uid, for example.

What are your export options?  (Do you have nosubtreecheck turned on?)

--b.

> Note on a different (client) issue: Trying the above with the direct
> parent (i.e. chmod 0 ..) fails with ESTALE due to lookup of "c" in "b"
> to which access has been revoked (no reboot needed):
> 
> 	$ mkdir -p a/b/c
> 	$ cd a/b/c
> 	$ chmod 0 ..
> 	$ ls -a
> 	ls: .: Stale NFS file handle
> 	$ chmod 755 ..
> 	$ ls -a
> 	.  ..
> 	$
> 
> -- 
> Frank
> -
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html