On Aug 7, 2008, at 12:29 PM, Chuck Lever wrote:
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.
Confirmed. The kernel's mountd client doesn't even bother to
unmarshal the auth flavor list in the server's reply.
I'll work on a fix.
--
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
