On Aug 6, 2008, at 2:21 PM, Sergey Bolshakov wrote:
"Chuck" == Chuck Lever <chuck.lever@xxxxxxxxxx> writes:
[skipped]
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).
I've seen same thing with degraded sec=none having SUSE 9SP3
nfs-utils-1.0.6-103.23 on server side and 1.1.2-3899db6d
on client side, so 3c1bb23c seems causing problems.
That's plausible. The patch description claims the new client
shouldn't choose AUTH_NULL even if it's in the list, so there may be a
bug in the logic introduced by 3c1bb23c.
The new nfs(5) man page says sec=sys is the default if no security
flavor is explicitly specified. This is incorrect (or an
oversimplification at the very least), given the security negotiation
that goes on in mount.nfs. That's another bug that should be fixed
when this problem is addressed.
I doubt similar security flavor negotiation occurs in the kernel's
mountd client, in the text-based case; thus the default sec=sys is
always used when no security flavor is specified. That's probably yet
another bug.
I'm still at a loss to explain how this would show up on 2.6.26
clients. mount.nfs from nfs-utils-1.1.1 and beyond on that kernel
should be using the text-based interface, so changing nfs-utils
shouldn't have any effect on this behavior.
--
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
