Summary: | net-fs/nfs-utils-1.2.1 breaks nfs mounts: "an incorrect mount option was specified" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | ferret <ferret-bgo> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | bbutscheidt, benjamin1506, grubba, kfm, rodrigo, rossi.f, tom, vereecke.jan |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
ferret
2009-12-03 15:05:06 UTC
Should add: no, I don't have nfs v4 support in my kernel. Didn't need it yesterday... :) Tried relevant-looking post-1.2.1 upstream patch: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=2498a68b1bec01d0ee8a63962b314140e8289036 But, did not help. I suspect it's a case of bad default. Check your nfsmount.conf. If that fails, you can always try adding 'vers=3' to your mount options. Don't have a nfsmount.conf Don't have any files in /etc that mention vers= Since it starts happenening between 1.2.0 and 1.2.1 I diffed the files from those two packages. The only differences are in the compiled binaries, and doc/man pages. So it is not a configuration issue. The change is in the code. 'vers=3' was meant for fstab. In the other bug, that helped. Though I think there should be nfsmount.conf laying around somewhere. (I suspect (after looking at nfs-utils code), that you're simply hitting a code branch, that you could have before) Hi, I have the same problem. I mount nfs disks with autofs. Problems started with kernel 2.6.32. When I boot 2.6.31, nfs mount works again. I tried to compile nfsv4 into kernel. The error message disappear from log, but still not mount. Then I added "vers=3" to autofs config, restart it and nfs works again. So it looks like the default nsf version was changed in 2.6.32. If it is not specified, v4 is used. It's the other way around: in nfs-utils code there's a version check, that makes v4 default if running on >=2.6.32. Same here after update of kernel 2.6.31 and again,adding vers=3 to the mount options helped. (In reply to comment #7) > It's the other way around: > in nfs-utils code there's a version check, > that makes v4 default if running on >=2.6.32. But v4 is still marked as EXPERIMENTAL in 2.6.36 I use here. Turning an unstable(experimental) code as default? Isn't this a system breaker? I hit the same problem not being able to mount nfs anymore since recent update of nfs ebuilds. I make Plüss words mine. People simply updating their systems to packages marked as stable are getting their nfs mounts broken because nfs-utils _forces_ NFS 4 use despite NFS 4 being marked as experimental in the kernel and despite the instructions available at "man 5 nfs" on the "nfsvers" option: "If this option is not specified, the client negociate a suitable version with the server, trying version 4 first, version 3 second, and version 2 last." What is really happening with net-fs/nfs-utils-1.2.3-r1 is that nfs version 4 is being forced, and when it fails for lack of support on the server side, for example, the mount fails completely. Just to complete this report, it seems that including the option "nfsvers=3" in each nfs mount in /etc/fstab can prevent nfs-utils from forcing NFS 4 on the mount request. I also included "-nfsvers4" in my use flags. I'm not sure this is really necessary but I'm just trying to be on the safe side here as non-working nfs mounts are really troublesome. This bug has more than a year and even with this info available net-fs/nfs-utils-1.2.3-r1 was marked as stable. Why create havok on nfs users this way? I believe I finally discovered the problem here. It seems to be two-fold. nfs-utils 1.2.3-r1 tries a NFS 4 connection even if 1. there is no NFS 4 client support in the kernel 2. there is a -nfsver4 USE flag defined. I believe the ebuild should check for these two conditions. If any of them is present, a NFS 4 connection should not be even tried. After including NFS 4 client support in the client kernel my NFS mounts are working even without NFS 4 server support in the server kernel. The error is reported by fs/nfs/super.c in Linux kernel, when version4 protocol is used and NFS4 support was not built-in. Interaction with a kernel module is performed by mount.nfs from nfs-utils. When no NFS version was specified, nfs_try_mount in stropts.c calls nfs_autonegociate, which tries to use NFSv4 first. When no NFSv4 support is built-in, errno is set to 22=EINVAL This special case is not handled by nfs_autonegociate and it aborts with error. Hence, mount with NFSv3 is never tried. BUGS: - nfs-utils uses NFSv4 even when --enable-nfsv4 option was not specified. - in fact, --enable-nfsv4 has almost no effect - nfs-utils does not handle EINVAL errno value. SOLUTION: - recompile kernel and add NFSv4 support even if you do not use it. - add nfsvers=3 (or vers=3) to mount options TODO: - in case of autofs with ldap I don't know what to modify to get nfsvers=3 appended to mount options I just noticed the following: | # strings /sbin/mount.nfs | grep vers | -V Print version | %s: requested NFS version or transport protocol is not supported | nfsvers | mountvers | %s: parsing error on 'vers=' option | %s: invalid value for 'vers=' option | %s: parsing error on 'nfsvers=' option | %s: invalid value for 'nfsvers=' option | %s: trying %s prog %lu vers %lu prot %s port %d | %s: prog %lu, trying vers=%lu, prot=%u | %s: invalid value for 'mountvers=' option | %s: Please use '-t nfs4' instead of '-o vers=4' | %s: NFS version %ld is not supported | %s: NFS mount version %ld is not supported | %s: pinging: prog %d vers %d prot %s port %d | mountvers=%lu | vers=4 | NOTE: this default has changed since nfs-utils version 1.0.x Note the next to last line... Editing the binary and changing that 'vers=4' to 'vers=3' solved my immediate problem (nfs mounting of auto_home). net-fs/nfs-utils-1.2.3-r1 is still broken. These new nfs-utils packages break functionality and should not be marked stable. Please mark them ~arch. |