On Aug 7, 2008, at 11:05 AM, Lucas Nussbaum wrote:
On 06/08/08 at 12:21 -0400, Chuck Lever wrote:
On Aug 5, 2008, at 3:28 PM, Rasmus Bøg Hansen wrote:
Chuck Lever <chuck.lever@xxxxxxxxxx> writes:
On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
Chuck Lever <chuck.lever@xxxxxxxxxx> writes:
On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
"J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes:
On Fri, Aug 01, 2008 at 11:15:33PM +1000, Aníbal Monsalve
Salazar
wrote:
On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson
wrote:
I just cut the 1.1.3 nfs-utils release. Unfortunately
I'm having
issues accessing my kernel.org account so for the moment the
tar ball is only available on SourceForge:
http://sourceforge.net/projects/nfs
[...]
1.1.3 clients don't work with a 1.0.10 server anymore.
Very weird--it might make sense if upgrading nfs-utils broke
the
mount
itself, but here it seems the mount is succeeding and
subsequent
file
access (which I'd expect to only involve the in-kernel client
code) is
failing. Maybe there's some difference in the mount options?
What does
/proc/self/mounts say? I assume these are all v2 or v3
mounts?
I discovered today that I was no longer able to write to the v3
mount on
my 1.1.2 server. I checked /proc/mounts and noticed sec=null
on
the
mount. Either adding sec=sys to the client's mount options or
downgrading to nfs-common 1.1.2 on the client fixes the
problem.
That would do it!
So it sounds like there's a bug that causes mount.nfs to get the
default
mount options wrong?
I'm not sure I'm following this. I can't think of a user-space
mount.nfs change in 1.1.3 that would affect the sec= option.
Paul, which kernel are you running on your clients?
Either 2.6.26 or 2.6.27-rc1+. I'll double-check.
It would be interesting if you could try both. I suspect 2.6.26
doesn't exhibit this problem, as 27-rc1 has changes in the NFS
mount
parser that affect "sec=".
I had the problem with 2.6.26. I didn't try 2.6.27-rc1 on that
machine.
Also, enabling NFS mount debugging messages when performing the
mount
that eventually doesn't work would be enlightening (for me).
Either:
I won't be around that machine for a week or so.
Whichever one it was, the problem was present with 1.1.3
installed,
and
not present with 1.1.2 installed.
Same here.
Thanks for the report.
In addition to the debugging mentioned above, anyone encountering
this
regression can also try a git bisect on nfs-utils (between 1.1.2 and
1.1.3).
Hi,
Some more info on this:
The problem only arises when the debian specific patch
debian/patches/05-default-use-old-mount-interface.patch is applied.
(it works fine with stock 1.1.3)
OK, that makes it more clear that the presenting problem is in the
legacy mount.nfs path, and explains why perhaps the reporters were
finding this problem on late model kernels that should be using the
text-based interface.
The text-based interface is probably not correct either, but is using
a default setting that avoids this problem, rather than negotiating
based on the server's list.
I'll have to get off my butt and look at the kernel's mountd client to
verify this.
git bisecting with that patch applied shows that the first bad
commit is:
commit 3c1bb23c0379864722e79d19f74c180edcf2c36e
Author: bc Wong <bcwong@xxxxxxxxx>
Date: Tue Mar 18 09:30:44 2008 -0400
There were 2 things wrong with auth flavour ordering:
- Mountd used to advertise AUTH_NULL as the first flavour on
the list, which means that it prefers AUTH_NULL to anything
else (as per RFC 2623 section 2.7).
- Mount.nfs used to scan the returned list in reverse order,
and stopping at the first AUTH_NULL or AUTH_SYS encountered.
If a server advertises (AUTH_SYS, AUTH_NULL), it will by
default choose AUTH_NULL and have degraded access.
I've fixed mount.nfs to scan from the beginning. For mountd,
it does not advertise AUTH_NULL anymore. This is necessary
to avoid backward compatibility issue. If AUTH_NULL appears
in the list, either the new or the old client will choose
that over AUTH_SYS.
Tested the server/client combination against the previous
versions, as well as Solaris and FreeBSD.
Signed-off-by: bc Wong <bcwong@xxxxxxxxx>
Signed-off-by: Steve Dickson <steved@xxxxxxxxxx>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
