Bug 207385 - NFS4: Couldn't follow remote path
Summary: NFS4: Couldn't follow remote path
Status: ASSIGNED
Alias: None
Product: File System
Classification: Unclassified
Component: NFS (show other bugs)
Hardware: All Linux
: P1 low
Assignee: Anna Schumaker
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-21 11:10 UTC by Vladimir Erilov
Modified: 2021-01-20 16:25 UTC (History)
8 users (show)

See Also:
Kernel Version: 5.6 onward
Tree: Mainline
Regression: No


Attachments
bisect log (5.32 KB, application/octet-stream)
2020-04-21 11:10 UTC, Vladimir Erilov
Details

Description Vladimir Erilov 2020-04-21 11:10:37 UTC
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.
Comment 1 Vladimir Erilov 2020-04-21 15:59:04 UTC
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
...
Comment 2 Ian Kent 2020-04-27 11:18:09 UTC
(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
Comment 3 Vladimir Erilov 2020-04-29 14:24:29 UTC
(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.
Comment 4 Vladimir Erilov 2020-05-03 11:18:42 UTC
Kinda "solved" it with explicit setting in /etc/nfsmount.conf:
```
[ Server "_gateway" ]
Defaultvers=3
```
No more NFS4-errors when mounting NFS3 share.
Comment 5 sander44 2020-07-24 15:11:12 UTC
Hi Ian Kent and Vladimir Erilov,

This issue appear in 5.7.8 with Ubuntu OS and NFSv3.
Comment 6 Vladimir Erilov 2020-07-24 17:11:44 UTC
This is not an issue but a feature. Use explicit NFS v3 setting in /etc/fstab to override auto detection if NFS server version.
Comment 7 sander44 2020-07-25 06:49:55 UTC
Hi Vladimir Erilov,

I use automount(autofs) to be able to mount NFSv3 points.
Comment 8 Bodo Eggert 2020-10-08 06:38:51 UTC
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.
Comment 9 Antonio 2020-11-05 19:43:35 UTC
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
Comment 10 Robert Voje 2021-01-20 16:25:29 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.