[PATCH] NFS Client mounts hang when exported directory do not exist
Eric Paris
eparis at redhat.com
Fri Apr 11 18:35:02 UTC 2008
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
More information about the Fedora-kernel-list
mailing list