I can't automount my shares. If I try to mount them manually it fails as well: root@lynx2:/usr/src/linux(118)# mount -t nfs -v caiman:/home_caiman /mnt/test mount.nfs: timeout set for Sat Jan 31 21:55:07 2015 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.86,clientaddr=192.168.1.43' mount.nfs: mount(2): Invalid argument mount.nfs: an incorrect mount option was specified 'mount -t nfs -o nfsvers=3 caiman:/home_caiman /mnt/test' works: root@lynx2:/usr/src/linux(123)# mount -t nfs -o nfsvers=3 caiman:/home_caiman /mnt/test root@lynx2:/usr/src/linux(124)# ll /mnt/test total 8 drwxrwxr-x 5 root mseifert 63 Nov 30 18:05 ftp/ drwx------ 2 root root 4096 Jan 21 2011 lost+found/ drwxr-xr-x 64 rose rose 4096 Jan 31 21:08 rose/ root@lynx2:/usr/src/linux(125)# genlop -t nfs-utils | tail Tue Dec 23 21:15:43 2014 >>> net-fs/nfs-utils-1.3.1 merge time: 3 minutes and 52 seconds. Wed Dec 24 23:27:02 2014 >>> net-fs/nfs-utils-1.3.1-r1 merge time: 2 minutes and 41 seconds. Sat Jan 31 18:23:10 2015 >>> net-fs/nfs-utils-1.3.2 merge time: 1 minute and 57 seconds. The nfs server was upgraded from 3.18.3-gentoo to 3.18.5-gentoo with identical kernel config.
Same here on an ~amd64 system... downgrading to nfs-utils-1.3.1-r1 works, but both nfs-utils-1.3.2 and nfs-utils-1.3.2-r1 don't work. Looks like rpc.statd is failing to start: -- Unit rpc-statd.service has begun starting up. rpc.statd[2206]: Version 1.3.2 starting rpc.statd[2206]: Flags: TI-RPC rpc.statd[2206]: Running as root. chown /var/lib/nfs to choose different user -- The start-up result is done. rpc-statd.service start operation timed out. Terminating. Failed to start NFS status monitor for NFSv2/3 locking.. -- Subject: Unit rpc-statd.service has failed emerge --info: Portage 2.2.15 (python 3.3.5-final-0, unavailable, gcc-4.9.2, glibc-2.20-r1, 3.17.8-gentoo-r1 x86_64) ================================================================= System uname: Linux-3.17.8-gentoo-r1-x86_64-Intel-R-_Core-TM-_i7-3770_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 16412484 total, 13230264 free KiB Swap: 0 total, 0 free Timestamp of tree: Unknown sh bash 4.3_p33-r1 ld GNU ld (Gentoo 2.24 p1.4) 2.24 distcc 3.2rc1 x86_64-pc-linux-gnu [enabled] dev-lang/python: 2.7.9-r1, 3.3.5-r1, 3.4.2 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.10.3-r1, 1.11.6-r1, 1.12.6, 1.15 sys-devel/binutils: 2.24-r3 sys-devel/libtool: 2.4.5 sys-kernel/linux-headers: 3.18 (virtual/os-headers) Repositories: gentoo steam-overlay jtriley x-portage ACCEPT_KEYWORDS="~amd64" ACCEPT_LICENSE="*" CFLAGS="-O2 -pipe -march=ivybridge -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=ivybridge" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -march=ivybridge -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=ivybridge" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs config-protect-if-modified distcc distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" GENTOO_MIRRORS="http://gentoo.ussg.indiana.edu/ http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/steam /var/lib/layman/jtriley /usr/local/portage" USE="X aac acpi alsa ao bluray cairo cjk consolekit dbus dri dvd emacs exif fbcon ffmpeg flac fuse gnome gnome-keyring gstreamer gtk gtk3 introspection jpeg kde libnotify mad mmx mp3 mp4 musepack ogg opengl png policykit pulseaudio qt3support smp spell sse sse2 steamruntime svg threads vaapi vdpau vorbis x264 xcomposite xft xinerama xv zsh-completion" Unset: EMERGE_DEFAULT_OPTS, PORTAGE_BUNZIP2_COMMAND
I have just the same as cshei@cs.indiana.edu. NFS mounting fails with nfs-utils-1.3.2 and nfs-utils-1.3.2-r1. I can't restart rpc-statd.service with nfs-utils-1.3.2*. If I downgrade nfs-utils to version 1.3.1-r1, which also downgrades libevent from version 2.1.5 to 2.0.22 NFS mounting works again: root@lynx:/usr/portage(40)# systemctl restart rpc-statd.service Job for rpc-statd.service failed. See "systemctl status rpc-statd.service" and "journalctl -xe" for details. root@lynx:/usr/portage(41)# qlist -Iv nfs-utils net-fs/nfs-utils-1.3.2-r1 root@lynx:/usr/portage(42)# echo '>=net-fs/nfs-utils-1.3.2' >> /etc/portage/package.mask root@lynx:/usr/portage(43)# emerge -v1 nfs-utils ... root@lynx:/usr/portage(46)# systemctl daemon-reload root@lynx:/usr/portage(47)# systemctl restart rpc-statd.service root@lynx:/usr/portage(48)# systemctl status rpc-statd.service ● rpc-statd.service - NFS status monitor for NFSv2/3 locking. Loaded: loaded (/usr/lib64/systemd/system/rpc-statd.service; static; vendor preset: enabled) Active: active (running) since Sun 2015-02-01 10:13:04 CET; 11s ago Process: 25376 ExecStart=/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=0/SUCCESS) Main PID: 25378 (rpc.statd) CGroup: /system.slice/rpc-statd.service └─25378 /sbin/rpc.statd --no-notify Feb 01 10:13:04 lynx rpc.statd[25378]: Version 1.3.1 starting Feb 01 10:13:04 lynx rpc.statd[25378]: Flags: TI-RPC Feb 01 10:13:04 lynx rpc.statd[25378]: Running as root. chown /var/lib/nfs to choose different user Feb 01 10:13:04 lynx systemd[1]: Started NFS status monitor for NFSv2/3 locking.. root@lynx:/usr/portage(49)# ll /net/caiman/home_caiman total 8 drwxr-xr-x 2 root root 0 Feb 1 10:13 ftp/ drwx------ 2 root root 4096 Jan 21 2011 lost+found/ drwxr-xr-x 64 rose rose 4096 Feb 1 07:15 rose/
There are two different problems at work here: server (nfs.statd not starting) and client-side (refused mounts). Please don't confuse the two. So far I found that the *client* side problem is likely caused (it was in my case) by a lack of CONFIG_NFS_V4_2=y in the kernel; adding that and rebooting made automounting with 1.3.2 work. Apparently mounting without explicit protocol version will now attempt 4.2 first and does not fall back to 4.1 properly if 4.2 is not enabled at all. That is also why mounting manually with e.g. -o nfsvers=4.1 will work. So either add the kernel option or explicitly set your automount maps to 4.1 and things should be back to normal for clients. Server-side is a different problem.
(In reply to Holger Hoffstätte from comment #3) > Server-side is a different problem. ..which apparently just got fixed in 1.3.2-r1: statd now starts properly. So to recap, make sure your clients have CONFIG_NFS_V4_2=y enabled.
(In reply to Holger Hoffstätte from comment #3) > There are two different problems at work here: server (nfs.statd not > starting) and client-side (refused mounts). Please don't confuse the two. > > So far I found that the *client* side problem is likely caused (it was in my > case) by a lack of CONFIG_NFS_V4_2=y in the kernel; adding that and > rebooting made automounting with 1.3.2 work. Apparently mounting without > explicit protocol version will now attempt 4.2 first and does not fall back > to 4.1 properly if 4.2 is not enabled at all. That is also why mounting > manually with e.g. -o nfsvers=4.1 will work. So either add the kernel option > or explicitly set your automount maps to 4.1 and things should be back to > normal for clients. > > Server-side is a different problem. I do not see a CONFIG_NFS_V4_2 kernel version: root@lynx:/usr/portage(56)# zgrep CONFIG_NFS /proc/config.gz CONFIG_NFS_FS=y CONFIG_NFS_V2=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y # CONFIG_NFS_SWAP is not set # CONFIG_NFS_V4_1 is not set # CONFIG_NFS_USE_LEGACY_DNS is not set CONFIG_NFS_USE_KERNEL_DNS=y CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V3_ACL is not set CONFIG_NFSD_V4=y # CONFIG_NFSD_FAULT_INJECTION is not set CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_COMMON=y Is this kernel version only visible, if CONFIG_NFS_V4_1 is set?
(In reply to cshei from comment #1) > Same here on an ~amd64 system... downgrading to nfs-utils-1.3.1-r1 works, > but both nfs-utils-1.3.2 and nfs-utils-1.3.2-r1 don't work. Looks like > rpc.statd is failing to start: > > -- Unit rpc-statd.service has begun starting up. > rpc.statd[2206]: Version 1.3.2 starting > rpc.statd[2206]: Flags: TI-RPC > rpc.statd[2206]: Running as root. chown /var/lib/nfs to choose different > user > > -- The start-up result is done. > rpc-statd.service start operation timed out. Terminating. > Failed to start NFS status monitor for NFSv2/3 locking.. > -- Subject: Unit rpc-statd.service has failed That /looks/ like a different problem already addressed in -r1: *nfs-utils-1.3.2-r1 (31 Jan 2015) 31 Jan 2015; Tim Harder <radhermit@gentoo.org> -nfs-utils-1.3.2.ebuild, +nfs-utils-1.3.2-r1.ebuild, files/rpc.statd.initd: Force rpc.statd into the background.
(In reply to Juergen Rose from comment #5) > Is this kernel version only visible, if CONFIG_NFS_V4_1 is set? Yes, 4_2 depends on 4_1 - see e.g. http://cateee.net/lkddb/web-lkddb/NFS_V4_2.html My settings on the client are: holger>grep "^CONFIG_NFS_*" /etc/kernels/kernel-config-x86_64-3.18.5 CONFIG_NFS_FS=m CONFIG_NFS_V2=m CONFIG_NFS_V3=m CONFIG_NFS_V4=m CONFIG_NFS_V4_1=y CONFIG_NFS_V4_2=y CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org" CONFIG_NFS_V4_SECURITY_LABEL=y CONFIG_NFS_FSCACHE=y CONFIG_NFS_USE_KERNEL_DNS=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_V4=y CONFIG_NFS_COMMON=y This should get you going.
> That /looks/ like a different problem already addressed in -r1: > > *nfs-utils-1.3.2-r1 (31 Jan 2015) > > 31 Jan 2015; Tim Harder <radhermit@gentoo.org> -nfs-utils-1.3.2.ebuild, > +nfs-utils-1.3.2-r1.ebuild, files/rpc.statd.initd: > Force rpc.statd into the background. That's a workaround for openrc? I think the fix is in the following attachment.
Created attachment 395316 [details, diff] Patch to daemonise rpc-statd
(In reply to Chris Mayo from comment #8) > > That /looks/ like a different problem already addressed in -r1: > > > > *nfs-utils-1.3.2-r1 (31 Jan 2015) > > > > 31 Jan 2015; Tim Harder <radhermit@gentoo.org> -nfs-utils-1.3.2.ebuild, > > +nfs-utils-1.3.2-r1.ebuild, files/rpc.statd.initd: > > Force rpc.statd into the background. > > That's a workaround for openrc? I think the fix is in the following > attachment. Yep, I'm running systemd for GNOME 3, so -r1 didn't fix the problem for me. Dropping your patch into /etc/portage/patches and modifying a local copy of the ebuild to call epatch_user fixed the problem, thanks!
(In reply to cshei from comment #10) > Yep, I'm running systemd for GNOME 3, so -r1 didn't fix the problem for me. > Dropping your patch into /etc/portage/patches and modifying a local copy of > the ebuild to call epatch_user fixed the problem, thanks! This should be fixed in >=nfs-utils-1.3.2-r2 since we now pull upstream's patch too. I also added epatch_user if you need to do stuff like this in the future.
Closing since the other mounting issue seems to be answered in the comments, if not please reopen.
Re-opening, since adding the recommended mount option does absolutely nothing to fix the mount error below. And before I go recompile more than a dozen kernels (half of them on embedded boxes) to enable a version option I don't even use, I guess I'd like a more clear explanation and (hopefully) a better fix. Masking the newer nfs-utils seems like a much easier interim solution... Current mount options "defaults" Current init setup: openrc (no systemd) # mount -v /usr/portage/distfiles/ mount.nfs: timeout set for Wed Feb 4 14:50:56 2015 mount.nfs: trying text-based options 'nfsvers=4.1,addr=192.168.0.14,clientaddr=192.168.0.7' mount.nfs: mount(2): Invalid argument mount.nfs: an incorrect mount option was specified
(In reply to Steve Arnold from comment #13) > [...] adding the recommended mount option does absolutely > nothing to fix the mount error below. And before I go recompile more than a > dozen kernels (half of them on embedded boxes) [...] > > Current mount options "defaults" > > Current init setup: openrc (no systemd) > > # mount -v /usr/portage/distfiles/ > mount.nfs: timeout set for Wed Feb 4 14:50:56 2015 > mount.nfs: trying text-based options > 'nfsvers=4.1,addr=192.168.0.14,clientaddr=192.168.0.7' > mount.nfs: mount(2): Invalid argument > mount.nfs: an incorrect mount option was specified This is happening in my Gentoo client with systemd because the client defaults to version >4 (nfsvers=4.1 above), which is not supported by the server (in my case with an old server at least). An easy workaround is to ask the client to use NFS version 3 with the option nfsvers=3, which works in my case.
Also just hit this bug (the part about "an incorrect mount option was specified"). I have nfsv41 use flag disabled, and also both 4.1 and 4.2 version support disabled in kernel. Specifying "vers=4" option in fstab helps, but this is just a workaround for this regression. First of all it's strange to have nfsv41 USE flag disabled, but nfs 4.2 support enabled in utils (there is no nfsv42 USE flag). Secondly ebuild doesn't check kernel configuration for mentioned options, so there is no way for user to know that they are needed. I would say that correct behavior for mount.nfs4 is to fallback to older versions if mount fails for newer variants - it doesn't happen. Mostly it's an upstream issue, but still it's bad to break stuff like that in distributions, I'd vote for masking until this is fixed.
(In reply to parafin from comment #15) > … I'd vote for masking until this is fixed. I don't know if this bug still exist but if it is I vote for the same : "masking until this is fixed"
