Description of problem: since some days strange error messages are found in kernel log once I try to access QNAP storage via NFS and automount Version-Release number of selected component (if applicable): autofs-5.1.6-1.fc31.x86_64 kernel-5.6.6-200.fc31.x86_64 How reproducible: always on first run on ls /net Steps to Reproduce: 1. ls /net 2. dmesg Actual results: 26 lines of NFS4: Couldn't follow remote path 39 lines of nfs: Deprecated parameter 'intr' Expected results: no such lines Additional info: "intr" option is hardcoded in /etc/auto.net try after next reboot with removed one: -opts="-fstype=nfs,hard,intr,nodev,nosuid" +opts="-fstype=nfs,hard,nodev,nosuid" The other warning is discussed also here: https://bugzilla.kernel.org/show_bug.cgi?id=207385 QNAP has 26 exports defined, but no NFS4 active: # rpcinfo -u QNAP nfs 3 program 100003 version 3 ready and waiting # rpcinfo -u QNAP nfs 4 rpcinfo: RPC: Program/version mismatch; low version = 2, high version = 4 program 100003 version 4 is not available
(In reply to Peter Bieringer from comment #0) > Description of problem: > since some days strange error messages are found in kernel log once I try to > access QNAP storage via NFS and automount So you don't get these messages when you mount the share manually? > > Version-Release number of selected component (if applicable): > autofs-5.1.6-1.fc31.x86_64 > kernel-5.6.6-200.fc31.x86_64 > > How reproducible: > always on first run on > ls /net > > Steps to Reproduce: > 1. ls /net > 2. dmesg > > Actual results: > 26 lines of > > NFS4: Couldn't follow remote path > > > 39 lines of > nfs: Deprecated parameter 'intr' > > > Expected results: > no such lines > > > Additional info: > "intr" option is hardcoded in /etc/auto.net Use the -hosts option in the master map entry for /net instead, I don't think that will make a difference to the messages but I don't think it uses the intr option. > > try after next reboot with removed one: > > -opts="-fstype=nfs,hard,intr,nodev,nosuid" > +opts="-fstype=nfs,hard,nodev,nosuid" > > > The other warning is discussed also here: > https://bugzilla.kernel.org/show_bug.cgi?id=207385 So your referring to something that appears to have nothing to do with autofs as a reference to what your seeing with autofs ... > > > QNAP has 26 exports defined, but no NFS4 active: > > # rpcinfo -u QNAP nfs 3 > program 100003 version 3 ready and waiting > # rpcinfo -u QNAP nfs 4 > rpcinfo: RPC: Program/version mismatch; low version = 2, high version = 4 > program 100003 version 4 is not available I don't know how to get hold of the QNAP kernel config to check if NFS v4 is supposed to be supported by their kernel. Historically I don't remember seeing v4 mounts from QNAP devices. The problem with logging this against autofs is that autofs runs the mount command to mount the share and has nothing to do with the actual communication between the NFS client and server once it's mounted. Ian
(In reply to Ian Kent from comment #1) > > > > The other warning is discussed also here: > > https://bugzilla.kernel.org/show_bug.cgi?id=207385 > > So your referring to something that appears to have nothing to do with > autofs as a reference to what your seeing with autofs ... > Nevertheless I had a look at that kernel bug and the bisect essentially says that there are additional messages that are now logged which weren't logged before and the patch referred to in the bisect looks like it changes NFS debug only prints (I'm assuming the NFS dfprintk() macro is a debug print) to use the mount-API log macros which will log messages to the kernel log without consideration of debug settings. That doesn't mean those events are new only that they are now being logged. So I don't know if they are actually evidence of a a problem or not. Your case could well be caused by those same changes. Ian
(In reply to Ian Kent from comment #2) > Nevertheless I had a look at that kernel bug and the bisect essentially > says that there are additional messages that are now logged which weren't > logged before and the patch referred to in the bisect looks like it changes > NFS debug only prints (I'm assuming the NFS dfprintk() macro is a debug > print) to use the mount-API log macros which will log messages to the > kernel log without consideration of debug settings. Actually that's not quite right. The mount-API log macros will log messages to the kernel log if the new fsopen()/fsconfig()/fsmount() system calls are not used when performing the mount. That's probably the case for mount.nfs(8) in the nfs-utils package at this stage. Still, even if nfs-utils was updated it may still choose to print those messages, if it actually grabs them from the mount fd, don't know. Ian
regarding manual mount: mount -t nfs QNAP:/share /mnt/ I will get at least 2 times: Apr 28 08:35:34 client kernel: NFS4: Couldn't follow remote path Apr 28 08:35:34 client kernel: NFS4: Couldn't follow remote path nevertheless, mount is successful If I use mount -t nfs -o vers=3 QNAP:/share /mnt/ message is not appearing digged further, found in /etc/autofs.conf #mount_nfs_default_protocol = 3 mount_nfs_default_protocol = 4 => changed this to "3" and restarted autofs -> unmount automounted share -> ls share to automount -> same log lines :-( regarding auto.master /net -hosts is already existing and restart of autofs after the try-change in /etc/auto.net -opts="-fstype=nfs,hard,intr,nodev,nosuid" +opts="-fstype=nfs,hard,nodev,nosuid" is not helping at all, the related message is still appearing nfs: Deprecated parameter 'intr'
(In reply to Peter Bieringer from comment #4) > regarding manual mount: > > > mount -t nfs QNAP:/share /mnt/ > > I will get at least 2 times: > > Apr 28 08:35:34 client kernel: NFS4: Couldn't follow remote path > Apr 28 08:35:34 client kernel: NFS4: Couldn't follow remote path > > nevertheless, mount is successful Right, the NFS client is trying NFSv4 and falling back to NFSv3. As I was saying there probably is no difference other than the messages being printed where they weren't before the changes to convert NFS to use the new mount API. I've mentioned this to the patch submitter and the bug assignee must now also be aware of the surprising new messages appearing. So it's a matter of waiting I guess. When I did the changes for the new mount API for xfs I made a point of not changing the logging to use the macros seen in the NFS patch of the kernel bug for this very reason. There's more to do on the logging side of things for the new mount API IMHO. > > If I use > > mount -t nfs -o vers=3 QNAP:/share /mnt/ > > message is not appearing > > digged further, found in /etc/autofs.conf > > #mount_nfs_default_protocol = 3 > mount_nfs_default_protocol = 4 I thought I cleaned up the man page on that option. It is meant to match the setting of Defaultvers in /etc/nfsmount.conf, it's meant to tell autofs whether it needs to use it's special handling of NFSv4 mounts. I didn't want to try and parse a config. file I don't maintain, the format may change at any time. If you can change Defaultvers=3 in /etc/nfsmount.conf those messages should go away. If you also need to handle v4 mounts then you will need to add the NFS option nfsvers=3 (or vers=3) to your automounts. You can do that globally, per map or per-automount entry depending on your needs. You can't use nfs3 as you can for NFSv4 (eg. fstype=nfs4 in your map entry) because the default fstype=nfs means use mount.nfs defaults, so you need that extra option to specify you want NFSv3 mounts. > > => changed this to "3" and restarted autofs -> unmount automounted share -> > ls share to automount -> same log lines :-( > > > > regarding auto.master > > /net -hosts > > is already existing and restart of autofs after the try-change in > /etc/auto.net > -opts="-fstype=nfs,hard,intr,nodev,nosuid" > +opts="-fstype=nfs,hard,nodev,nosuid" > > is not helping at all, the related message is still appearing That's right, using -hosts will not use /etc/auto.net at all. Sounds like I'll need to check on the options I'm using internally. I'll fix that if it's broken. Ian
(In reply to Peter Bieringer from comment #0) > > QNAP has 26 exports defined, but no NFS4 active: > > # rpcinfo -u QNAP nfs 3 > program 100003 version 3 ready and waiting > # rpcinfo -u QNAP nfs 4 > rpcinfo: RPC: Program/version mismatch; low version = 2, high version = 4 > program 100003 version 4 is not available That's odd. I see the same rpcinfo output but I also see this on my client: gandalf:/work on /work type nfs4 (rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=a.b.c.d,local_lock=none,addr=a.b.c.e)
FEDORA-2020-c06cdca96c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c06cdca96c
FEDORA-2020-c06cdca96c has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c06cdca96c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c06cdca96c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-c06cdca96c has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.