Created attachment 288653 [details] bisect log On Linux 5.6 onwards whenever I mount my NFS share, kernel throws the following error: "NFS4: Couldn't follow remote path". Thing is, I have no NFSv4 shares as my router is capable to make NFSv3 shares only. Attaching bisect log and some details.
To be clear: my exports and NFS mounts are as follows: openm@RT-AC68U-ASMT:/tmp/home/root# exportfs -v /tmp/mnt/ASMT 10.0.0.5(rw,wdelay,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash) ┬─[openm@reiwa:~]─[01:55:58] ╰─>$ cat /etc/fstab ... _gateway:/tmp/mnt/ASMT/Music /home/openm/Music/ASMT nfs _netdev,noauto,users,x-systemd.automount,x-systemd.idle-timeout=1min,x-systemd.mount-timeout=10,timeo=14,noatime,nodev,nosuid,noexec 0 0 ...
(In reply to Vladimir Erilov from comment #0) > Created attachment 288653 [details] > bisect log > > On Linux 5.6 onwards whenever I mount my NFS share, kernel throws the > following error: "NFS4: Couldn't follow remote path". Thing is, I have no > NFSv4 shares as my router is capable to make NFSv3 shares only. > > Attaching bisect log and some details. Right, but the NFS client is probably trying a v4 connection first then falling back to v3 and the commit you point out changes what look like NFS debug prints to use the new mount-API log macros. They will log messages to the kernel log if the new fsopen(), fsconfig(),fsmount() system calls are not used when performing the mount. And that's probably the case with nfs-utils mount.nfs at this stage. Even if nfs-utils has been updated it may still choose to print those messages, if it actually grabs them from the mount fd context. So there's no way to know if these are new problems or were always present but not logged. I suspect the later. Ian
(In reply to Ian Kent from comment #2) > (In reply to Vladimir Erilov from comment #0) > > Created attachment 288653 [details] > > bisect log > > > > On Linux 5.6 onwards whenever I mount my NFS share, kernel throws the > > following error: "NFS4: Couldn't follow remote path". Thing is, I have no > > NFSv4 shares as my router is capable to make NFSv3 shares only. > > > > Attaching bisect log and some details. > > Right, but the NFS client is probably trying a v4 connection > first then falling back to v3 and the commit you point out > changes what look like NFS debug prints to use the new > mount-API log macros. > > They will log messages to the kernel log if the new fsopen(), > fsconfig(),fsmount() system calls are not used when performing > the mount. And that's probably the case with nfs-utils mount.nfs > at this stage. Even if nfs-utils has been updated it may still > choose to print those messages, if it actually grabs them from > the mount fd context. > > So there's no way to know if these are new problems or were > always present but not logged. I suspect the later. > > Ian Hi Ian, As I have 5.4 LTS kernel as well, I can check what it looks like when using it: $ journalctl --no-pager --no-hostname -b -p7 -g nfs -- Logs begin at Fri 2020-04-10 00:41:44 +10, end at Thu 2020-04-30 00:14:56 +10. -- Apr 29 23:40:07 systemd[1]: var-lib-nfs-rpc_pipefs.mount: Directory /var/lib/nfs/rpc_pipefs to mount over is not empty, mounting anyway. Apr 29 23:40:07 kernel: RPC: Registered tcp NFSv4.1 backchannel transport module. Apr 29 23:40:10 snapd[1437]: backend.go:121: snapd enabled NFS support, additional implicit network permissions granted Apr 29 23:40:11 systemd[1]: Condition check resulted in RPC security service for NFS client and server being skipped. Apr 29 23:40:11 systemd[1]: Condition check resulted in RPC security service for NFS server being skipped. Apr 29 23:40:11 systemd[1]: Reached target NFS client services. Apr 29 23:40:30 systemd[1]: Starting Notify NFS peers of a restart... Apr 29 23:40:30 systemd[1]: Started Notify NFS peers of a restart. Apr 29 23:40:30 kernel: calling init_nfs_fs+0x0/0x189 [nfs] @ 2278 Apr 29 23:40:30 kernel: FS-Cache: Netfs 'nfs' registered for caching Apr 29 23:40:30 kernel: initcall init_nfs_fs+0x0/0x189 [nfs] returned 0 after 165 usecs Apr 29 23:40:31 kernel: calling init_nfs_v4+0x0/0x38 [nfsv4] @ 2286 Apr 29 23:40:31 kernel: NFS: Registering the id_resolver key type Apr 29 23:40:31 kernel: initcall init_nfs_v4+0x0/0x38 [nfsv4] returned 0 after 12 usecs Apr 29 23:40:31 systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... Apr 29 23:40:31 systemd[1]: Started NFS status monitor for NFSv2/3 locking.. Apr 29 23:40:31 kernel: calling init_nfs_v3+0x0/0x1000 [nfsv3] @ 2543 Apr 29 23:40:31 kernel: initcall init_nfs_v3+0x0/0x1000 [nfsv3] returned 0 after 0 usecs So yeah, 5.4 doesn't produce this kind of warnings even on log level 7. In both cases, shares work fine, but the only problem is log level 3 NFS4 warnings since kernel 5.6, it looks like an extra flood for no good reason.
Kinda "solved" it with explicit setting in /etc/nfsmount.conf: ``` [ Server "_gateway" ] Defaultvers=3 ``` No more NFS4-errors when mounting NFS3 share.
Hi Ian Kent and Vladimir Erilov, This issue appear in 5.7.8 with Ubuntu OS and NFSv3.
This is not an issue but a feature. Use explicit NFS v3 setting in /etc/fstab to override auto detection if NFS server version.
Hi Vladimir Erilov, I use automount(autofs) to be able to mount NFSv3 points.
This is not a feature as long as neither the mountpoint nor the remote path are specified. Also I suspect hat the remote endpoints do not offer v4 at all, the message suggest that v4 would be supported but one of the path components is the problem. If I had not found this error message, I'd have to manually compare the list of desired mounts to the list of succeeded mounts only to waste hours of time before I find out that all the mounts actually did succeed. Then I'd create a bug report and eventually one of you would point out that the mounts succeed by using version 3 and not v4. TL;DR: Not helpful at all. It's a misfeature.
kernel 5.9.5: problem still persist. $ mount nasserver:/home/test /mnt -vvvv -o nfsvers=3 mount.nfs: timeout set for Thu Nov 5 20:43:34 2020 mount.nfs: trying text-based options 'nfsvers=3,addr=10.0.0.2' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 10.0.0.2 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying 10.0.0.2 prog 100005 vers 3 prot UDP port 45553 mount.nfs: mount(2): Input/output error mount.nfs: mount system call failed $ mount nasserver:/home/test /mnt -vvvv -o nfsvers=4 mount.nfs: timeout set for Thu Nov 5 20:44:20 2020 mount.nfs: trying text-based options 'vers=4,addr=10.0.0.2,clientaddr=10.0.0.1' mount.nfs: mount(2): Protocol error mount.nfs: Protocol error $ dmesg [gio nov 5 20:08:49 2020] NFS4: Couldn't follow remote path [gio nov 5 20:08:53 2020] NFS4: Couldn't follow remote path
Sorry, something went wrong, and I may have sent an empty post. I'll try again. I have only nfs4 mounts in my autofs config, and all mounts works. That is, they are mounted successfully with nfs4. But I still get the message "NFS4: Couldn't follow remote path" in my logs. I tried to add this to /etc/nfsmount.conf: [NFSMount_Global_Options] Defaultvers=3 That removed the message, but all mounts also reverted to nfs3 so it's not a good solution. I also thought it may be because some of my servers did not have a ipv6 export, so I made sure that all my mounts in autofs had ipv4 addresses and not hostnames, but that made no difference. My client are running ubuntu with kernel 5.8.0-36, and my servers mostly runs ubuntu with kernel 5.4.0-58.