Re: [PATCH] NFS Client mounts hang when exported directory do not exist

[Eric Paris <eparis@redhat.com>]

On Fri, 2008-04-11 at 12:10 -0400, Steve Dickson wrote:
> 
> Eric Paris wrote:
> > On Fri, 2008-04-11 at 11:12 -0400, Steve Dickson wrote:
> >> This patch fixes a regression that was introduced by the string based mounts. 
> >>
> >> nfs_mount() statically returns -EACCES for every error returned
> >> by the remote mounted. This is incorrect because -EACCES is
> >> an non-fatal error to the mount.nfs command. This error causes
> >> mount.nfs to retry the mount even in the case when the exported
> >> directory does not exist. 
> >>
> >> This patch maps the errors returned by the remote mountd into
> >> valid errno values, exactly how it was done pre-string based 
> >> mounts. By returning the correct errno enables mount.nfs 
> >> to do the right thing.
> > 
> > Does this mean the EACCES can/will again become fatal in mount.nfs like
> > it used to be?
> EACCES is still a non-fatal error as it was... 

"non-fatal error as it was"?  Huh?  Back in the days of binary mount
data it was fatal.  Try this on a new and old system.

mount -o context=system_u:object_r:httpd_t:s0 server:/export /import

old system it was fatal and we died instantly with EACCES telling the
user it was a permissions problem.  New system I have to waste 2 minutes
and then get a message about it timing out.  It wasn't a timeout, it was
a permission failure.  Users are going to be looking down the wrong
path..

> The problem is the 
> kernel was should have been returning ENOENT, which is a fatal error,
> instead of EACCES.

That may well have been your problem, but it doesn't change the fact the
EACCES has been a fatal error in mount.nfs until just recently.  Why was
it changed?  When is EACCES not fatal?

-Eric