Hi,
I recently packaged nfs-utils 1.2.1 for openSUSE and fairly quickly
got a bug report - "-o nfsvers=3" was needed to mount NFSv3
filesystems.
mount.nfs in 1.2.1 will first try a v4 mount but will fall-back to v3
if it gets ENOENT. This works fine.
However for kernel prior to 2.6.25, you don't get ENOENT, you get
EPERM.
In that case the fall-back to v3 doesn't happen and you get a failure
to mount.
So I think we need to fall back on EPERM as well. See below.
Thanks,
NeilBrown
diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
index b595649..68eb82b 100644
--- a/utils/mount/stropts.c
+++ b/utils/mount/stropts.c
@@ -657,8 +657,10 @@ static int nfs_try_mount(struct nfsmount_info *mi)
* To deal with legacy Linux servers that don't
* automatically export a pseudo root, retry
* ENOENT errors using version 3
+ * And for Linux servers prior to 2.6.25, retry
+ * EPERM
*/
- if (errno != ENOENT)
+ if (errno != ENOENT && errno != EPERM)
break;
}
}
On 11/23/2009 06:32 PM, Neil Brown wrote:
>
> Hi,
> I recently packaged nfs-utils 1.2.1 for openSUSE and fairly quickly
> got a bug report - "-o nfsvers=3" was needed to mount NFSv3
> filesystems.
>
> mount.nfs in 1.2.1 will first try a v4 mount but will fall-back to v3
> if it gets ENOENT. This works fine.
> However for kernel prior to 2.6.25, you don't get ENOENT, you get
> EPERM.
> In that case the fall-back to v3 doesn't happen and you get a failure
> to mount.
>
> So I think we need to fall back on EPERM as well. See below.
I already posted this patch on the v4 mailing list
http://linux-nfs.org/pipermail/nfsv4/2009-November/011595.html
but it got shot down... at least that's how I interpreted the
responses...
But I do thing we need this, since there are so many server
that will simple break if we don't... Agreed?
steved.
>
> Thanks,
> NeilBrown
>
>
> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
> index b595649..68eb82b 100644
> --- a/utils/mount/stropts.c
> +++ b/utils/mount/stropts.c
> @@ -657,8 +657,10 @@ static int nfs_try_mount(struct nfsmount_info *mi)
> * To deal with legacy Linux servers that don't
> * automatically export a pseudo root, retry
> * ENOENT errors using version 3
> + * And for Linux servers prior to 2.6.25, retry
> + * EPERM
> */
> - if (errno != ENOENT)
> + if (errno != ENOENT && errno != EPERM)
> break;
> }
> }
On Tue, Nov 24, 2009 at 09:29:47AM -0500, Steve Dickson wrote:
>
>
> On 11/23/2009 06:32 PM, Neil Brown wrote:
> >
> > Hi,
> > I recently packaged nfs-utils 1.2.1 for openSUSE and fairly quickly
> > got a bug report - "-o nfsvers=3" was needed to mount NFSv3
> > filesystems.
> >
> > mount.nfs in 1.2.1 will first try a v4 mount but will fall-back to v3
> > if it gets ENOENT. This works fine.
> > However for kernel prior to 2.6.25, you don't get ENOENT, you get
> > EPERM.
> > In that case the fall-back to v3 doesn't happen and you get a failure
> > to mount.
> >
> > So I think we need to fall back on EPERM as well. See below.
> I already posted this patch on the v4 mailing list
> http://linux-nfs.org/pipermail/nfsv4/2009-November/011595.html
> but it got shot down... at least that's how I interpreted the
> responses...
>
> But I do thing we need this, since there are so many server
> that will simple break if we don't... Agreed?
My position is that servers should either a) turn off NFSv4 or b) add a
pseudoroot, and that we should modify initscripts to make this harder to
screw up.
(For now (without automatic pseudoroot creation) we should by default be
running rpc.nfsd with -N 4; and adding the v4 support should be
something administrators do when they add a pseudoroot.)
((If this is really totally unfeasible, then I should quickly cue up a
revert for the patch I have queued for 2.6.33 which changes this error
again, to SERVERFAULT....))
--b.
>
> steved.
>
>
> >
> > Thanks,
> > NeilBrown
> >
> >
> > diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
> > index b595649..68eb82b 100644
> > --- a/utils/mount/stropts.c
> > +++ b/utils/mount/stropts.c
> > @@ -657,8 +657,10 @@ static int nfs_try_mount(struct nfsmount_info *mi)
> > * To deal with legacy Linux servers that don't
> > * automatically export a pseudo root, retry
> > * ENOENT errors using version 3
> > + * And for Linux servers prior to 2.6.25, retry
> > + * EPERM
> > */
> > - if (errno != ENOENT)
> > + if (errno != ENOENT && errno != EPERM)
> > break;
> > }
> > }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
J. Bruce Fields wrote:
> On Tue, Nov 24, 2009 at 09:29:47AM -0500, Steve Dickson wrote:
>>
>> On 11/23/2009 06:32 PM, Neil Brown wrote:
>>> Hi,
>>> I recently packaged nfs-utils 1.2.1 for openSUSE and fairly quickly
>>> got a bug report - "-o nfsvers=3" was needed to mount NFSv3
>>> filesystems.
>>>
>>> mount.nfs in 1.2.1 will first try a v4 mount but will fall-back to v3
>>> if it gets ENOENT. This works fine.
>>> However for kernel prior to 2.6.25, you don't get ENOENT, you get
>>> EPERM.
>>> In that case the fall-back to v3 doesn't happen and you get a failure
>>> to mount.
>>>
>>> So I think we need to fall back on EPERM as well. See below.
>> I already posted this patch on the v4 mailing list
>> http://linux-nfs.org/pipermail/nfsv4/2009-November/011595.html
>> but it got shot down... at least that's how I interpreted the
>> responses...
>>
>> But I do thing we need this, since there are so many server
>> that will simple break if we don't... Agreed?
>
> My position is that servers should either a) turn off NFSv4 or b) add a
> pseudoroot, and that we should modify initscripts to make this harder to
> screw up.
>
> (For now (without automatic pseudoroot creation) we should by default be
> running rpc.nfsd with -N 4; and adding the v4 support should be
> something administrators do when they add a pseudoroot.)
>
> ((If this is really totally unfeasible, then I should quickly cue up a
> revert for the patch I have queued for 2.6.33 which changes this error
> again, to SERVERFAULT....))
>
None helps new client systems who are forced to deal with older
server deployments. It is a bad thing to force customers to change
old servers simply because they want to deploy new clients. New
systems are generally just supposed to fit into existing networks
and not have to mold those networks to fit the new client's view
of the world.
Is this such a bad patch, to account for our own short sightedness
when designing the original NFSv4 server implementation? It is
even at the user level and not in the kernel...
Thanx...
ps
On Tue, 24 Nov 2009 15:56:16 -0500
"J. Bruce Fields" <[email protected]> wrote:
> On Tue, Nov 24, 2009 at 09:29:47AM -0500, Steve Dickson wrote:
> > > So I think we need to fall back on EPERM as well. See below.
> > I already posted this patch on the v4 mailing list
> > http://linux-nfs.org/pipermail/nfsv4/2009-November/011595.html
> > but it got shot down... at least that's how I interpreted the
> > responses...
Thanks for the reference ... clearly I am not keeping up with my
nfs mailing lists....
> >
> > But I do thing we need this, since there are so many server
> > that will simple break if we don't... Agreed?
Agreed that we certainly need something. We cannot expect people to
reconfigure their servers because they installed new software on the
client.
>
> My position is that servers should either a) turn off NFSv4 or b) add
> a pseudoroot, and that we should modify initscripts to make this
> harder to screw up.
In the ideal world, yes. Maybe this is best done in the kernel?
Can we synthesis an RPC-protocol-not-supported error if and NFSv4
request arrives from a client for which no pseudo-root is configured?
>
> (For now (without automatic pseudoroot creation) we should by default
> be running rpc.nfsd with -N 4; and adding the v4 support should be
> something administrators do when they add a pseudoroot.)
Hind sight is 20/20 they say. We probably should have done this, but
I think it is now too late to do anything useful in the init scripts.
>
> ((If this is really totally unfeasible, then I should quickly cue up a
> revert for the patch I have queued for 2.6.33 which changes this error
> again, to SERVERFAULT....))
Maybe - maybe not.
The situation on the client is that for a command that has
traditionally always performed a v3 or (before that) a v2 mount, we are
now trying a v4 mount.
I see that v4 attempt as opportunistic. If anything goes wrong I think
it is reasonable to go back to "the old way".
So I think this piece of code in mount.nfs should retry on any error at
all, so it would not matter whether you change again to SERVERFAULT.
But I think the best fix for the kernel is to get nfsd4_proc_compound
to return RPC_PROG_MISMATCH if there is no pseudo root, and then get
svc_process_common to handle this and fake up appropriate min/max
version numbers.
Thanks,
NeilBrown
Neil Brown wrote:
> On Tue, 24 Nov 2009 15:56:16 -0500
> "J. Bruce Fields" <[email protected]> wrote:
>
>> On Tue, Nov 24, 2009 at 09:29:47AM -0500, Steve Dickson wrote:
>>>> So I think we need to fall back on EPERM as well. See below.
>>> I already posted this patch on the v4 mailing list
>>> http://linux-nfs.org/pipermail/nfsv4/2009-November/011595.html
>>> but it got shot down... at least that's how I interpreted the
>>> responses...
>
> Thanks for the reference ... clearly I am not keeping up with my
> nfs mailing lists....
>
>
>>> But I do thing we need this, since there are so many server
>>> that will simple break if we don't... Agreed?
>
> Agreed that we certainly need something. We cannot expect people to
> reconfigure their servers because they installed new software on the
> client.
>
>> My position is that servers should either a) turn off NFSv4 or b) add
>> a pseudoroot, and that we should modify initscripts to make this
>> harder to screw up.
>
> In the ideal world, yes. Maybe this is best done in the kernel?
> Can we synthesis an RPC-protocol-not-supported error if and NFSv4
> request arrives from a client for which no pseudo-root is configured?
>
>> (For now (without automatic pseudoroot creation) we should by default
>> be running rpc.nfsd with -N 4; and adding the v4 support should be
>> something administrators do when they add a pseudoroot.)
>
> Hind sight is 20/20 they say. We probably should have done this, but
> I think it is now too late to do anything useful in the init scripts.
>
>> ((If this is really totally unfeasible, then I should quickly cue up a
>> revert for the patch I have queued for 2.6.33 which changes this error
>> again, to SERVERFAULT....))
>
> Maybe - maybe not.
>
> The situation on the client is that for a command that has
> traditionally always performed a v3 or (before that) a v2 mount, we are
> now trying a v4 mount.
> I see that v4 attempt as opportunistic. If anything goes wrong I think
> it is reasonable to go back to "the old way".
>
> So I think this piece of code in mount.nfs should retry on any error at
> all, so it would not matter whether you change again to SERVERFAULT.
>
> But I think the best fix for the kernel is to get nfsd4_proc_compound
> to return RPC_PROG_MISMATCH if there is no pseudo root, and then get
> svc_process_common to handle this and fake up appropriate min/max
> version numbers.
>
I think that we might be better off in the long run by taking a
step back and getting all of the plumbing right, instead of
cluttering up things to have knowledge which they have no
business knowing or worrying about.
If the NFSv4 server gets a request which involves the root file
handle and one has not been defined, then it should return the
error that is defined by the protocol. What the client chooses
to do with the error is up to it.
ps
On Tue, 24 Nov 2009 16:58:29 -0500
Peter Staubach <[email protected]> wrote:
> I think that we might be better off in the long run by taking a
> step back and getting all of the plumbing right, instead of
> cluttering up things to have knowledge which they have no
> business knowing or worrying about.
In principle, I completely agree.
>
> If the NFSv4 server gets a request which involves the root file
> handle and one has not been defined, then it should return the
> error that is defined by the protocol. What the client chooses
> to do with the error is up to it.
There is no error for "root file handle has not been defined".
The only errors available for PUTROOTFH are:
NFS4ERR_RESOURCE - which means "I'm exchausted after all the other
work you made me do" and shouldn't be returned for
the first op in a compound (that is an implied
restriction, not explicit).
NFS4ERR_SERVERFAULT which means something strange went wrong. This is
probably the closest, hence Bruce's recent patch to
use this error code.
NFS4ERR_WRONGSEC which means the security mechanism used by the
client isn't acceptable to the server. This is
certainly not usable in this context.
So NFS4ERR_SERVERFAULT would be OK simply because it is a wildcard.
But RPC_PROG_MISMATCH, which means "I don't support that version of the
protocol" would also be correct in this case and it trivial for the
client to interpret.
NeilBrown
Neil Brown wrote:
> On Tue, 24 Nov 2009 16:58:29 -0500
> Peter Staubach <[email protected]> wrote:
>
>> I think that we might be better off in the long run by taking a
>> step back and getting all of the plumbing right, instead of
>> cluttering up things to have knowledge which they have no
>> business knowing or worrying about.
>
> In principle, I completely agree.
>
>
>> If the NFSv4 server gets a request which involves the root file
>> handle and one has not been defined, then it should return the
>> error that is defined by the protocol. What the client chooses
>> to do with the error is up to it.
>
> There is no error for "root file handle has not been defined".
>
> The only errors available for PUTROOTFH are:
> NFS4ERR_RESOURCE - which means "I'm exchausted after all the other
> work you made me do" and shouldn't be returned for
> the first op in a compound (that is an implied
> restriction, not explicit).
> NFS4ERR_SERVERFAULT which means something strange went wrong. This is
> probably the closest, hence Bruce's recent patch to
> use this error code.
> NFS4ERR_WRONGSEC which means the security mechanism used by the
> client isn't acceptable to the server. This is
> certainly not usable in this context.
>
> So NFS4ERR_SERVERFAULT would be OK simply because it is a wildcard.
> But RPC_PROG_MISMATCH, which means "I don't support that version of the
> protocol" would also be correct in this case and it trivial for the
> client to interpret.
>
Well, to the last section, that is an RPC error and not an
NFS error. The RPC error, VERSMISMATCH, might be close, but
once again, is an RPC error and not an NFS error.
I don't think that an RPC error is correct to return if the
server is configured to support NFSv4. It might not be
correctly configured and completely configured, but in
theory, it is supposed to support NFSv4.
I'd probably buy into the SERVERFAULT as the most logical error.
Doing something better is tough because of the way that exports
and the NFS service are managed as distinct things. Perhaps if
the NFS service could detect that there were no NFSv4 exports,
then it could decline to register the NFSv4 service. Then, some
of the RPC errors would make sense.
The layering in the current implementations seems to make things
more difficult than it does make them easy. Just my opinion.
ps
On Tue, Nov 24, 2009 at 05:29:28PM -0500, Peter Staubach wrote:
> Neil Brown wrote:
> > On Tue, 24 Nov 2009 16:58:29 -0500
> > Peter Staubach <[email protected]> wrote:
> >
> >> I think that we might be better off in the long run by taking a
> >> step back and getting all of the plumbing right, instead of
> >> cluttering up things to have knowledge which they have no
> >> business knowing or worrying about.
> >
> > In principle, I completely agree.
> >
> >
> >> If the NFSv4 server gets a request which involves the root file
> >> handle and one has not been defined, then it should return the
> >> error that is defined by the protocol. What the client chooses
> >> to do with the error is up to it.
> >
> > There is no error for "root file handle has not been defined".
> >
> > The only errors available for PUTROOTFH are:
> > NFS4ERR_RESOURCE - which means "I'm exchausted after all the other
> > work you made me do" and shouldn't be returned for
> > the first op in a compound (that is an implied
> > restriction, not explicit).
> > NFS4ERR_SERVERFAULT which means something strange went wrong. This is
> > probably the closest, hence Bruce's recent patch to
> > use this error code.
> > NFS4ERR_WRONGSEC which means the security mechanism used by the
> > client isn't acceptable to the server. This is
> > certainly not usable in this context.
> >
> > So NFS4ERR_SERVERFAULT would be OK simply because it is a wildcard.
> > But RPC_PROG_MISMATCH, which means "I don't support that version of the
> > protocol" would also be correct in this case and it trivial for the
> > client to interpret.
> >
>
> Well, to the last section, that is an RPC error and not an
> NFS error. The RPC error, VERSMISMATCH, might be close, but
> once again, is an RPC error and not an NFS error.
We certainly don't want to modify the putrootfh code to return
prog_mismatch. First, it'd be annoying to figure out how to return an
rpc error at that point. Second, it looks odd to the client, which may
have already sent other NFSv4 rpc's without trouble, and may have
trouble handling the error at this point (it would be within its rights
to assume we do support v4 if v4 NULL succeeds). And third, because we
already have a simple established way to return prog_mismatch: just
start rpc.nfsd with -N 4.
> Doing something better is tough because of the way that exports
> and the NFS service are managed as distinct things. Perhaps if
> the NFS service could detect that there were no NFSv4 exports,
> then it could decline to register the NFSv4 service. Then, some
> of the RPC errors would make sense.
>
> The layering in the current implementations seems to make things
> more difficult than it does make them easy. Just my opinion.
You'd have to do an upcall to mountd to find out if there's an fsid=0
export before accepting any rpc's. Sounds awkward. It'd be easier if
we had an interface that allowed us to tell the server on NFS startup
whether there's a pseudoroot. But we do: /proc/net/nfsd/versions. And
if userspace is claiming to support v4 and then denying knowledge of any
pseudoroot in the mountd upcalls, then it's buggy.
(But, OK, agreed, we may just have to deal with the fact that lots of
servers are already configured that way and work around it on the
client.)
--b.
On Wed, 2009-11-25 at 09:22 +1100, Neil Brown wrote:
> On Tue, 24 Nov 2009 16:58:29 -0500
> Peter Staubach <[email protected]> wrote:
>
> > I think that we might be better off in the long run by taking a
> > step back and getting all of the plumbing right, instead of
> > cluttering up things to have knowledge which they have no
> > business knowing or worrying about.
>
> In principle, I completely agree.
>
>
> >
> > If the NFSv4 server gets a request which involves the root file
> > handle and one has not been defined, then it should return the
> > error that is defined by the protocol. What the client chooses
> > to do with the error is up to it.
>
> There is no error for "root file handle has not been defined".
>
> The only errors available for PUTROOTFH are:
> NFS4ERR_RESOURCE - which means "I'm exchausted after all the other
> work you made me do" and shouldn't be returned for
> the first op in a compound (that is an implied
> restriction, not explicit).
> NFS4ERR_SERVERFAULT which means something strange went wrong. This is
> probably the closest, hence Bruce's recent patch to
> use this error code.
> NFS4ERR_WRONGSEC which means the security mechanism used by the
> client isn't acceptable to the server. This is
> certainly not usable in this context.
>
> So NFS4ERR_SERVERFAULT would be OK simply because it is a wildcard.
> But RPC_PROG_MISMATCH, which means "I don't support that version of the
> protocol" would also be correct in this case and it trivial for the
> client to interpret.
One response that the spec allows is to accept the PUTROOTFH, but to
return either NFS4ERR_BADHANDLE or NFS4ERR_SERVERFAULT on any operation
that attempts to use the resulting filehandle.
Cheers
Trond
On 11/23/2009 06:32 PM, Neil Brown wrote:
>
> Hi,
> I recently packaged nfs-utils 1.2.1 for openSUSE and fairly quickly
> got a bug report - "-o nfsvers=3" was needed to mount NFSv3
> filesystems.
>
> mount.nfs in 1.2.1 will first try a v4 mount but will fall-back to v3
> if it gets ENOENT. This works fine.
> However for kernel prior to 2.6.25, you don't get ENOENT, you get
> EPERM.
> In that case the fall-back to v3 doesn't happen and you get a failure
> to mount.
>
> So I think we need to fall back on EPERM as well. See below.
Committed! We have to... but the line in the sand is drawn...
steved.