[1] https://git.kernel.org/pub/scm/linux/ke … 65601c4fb2
[2] https://github.com/archlinux/linux/comm … b1df254a12
According to the manpage
$ man 5 nfs
nfsvers=n The NFS protocol version number used to contact the server's NFS service. If the server
does not support the requested version, the mount request fails. If this option is not
specified, the client tries version 4.2 first, then negotiates down until it finds a ver‐
sion supported by the server.
It seems that there are issues with 4.2 on the QNAP NAS and the processes of negotiating down to a working/supported version is stuck/does not work properly.
As a temporary workaround (until this is fixed), you can use
mount.nfs -o nfsvers=4.0
@garloff did you test if the issue is still present in 5.17 releases candidates?
I can confirm that this unfortunately still persists with kernel 5.17.1-arch1-1
]]> /* Restrict FS_LOCATIONS to NFS v4.2+ to work around Qnap knfsd-3.4.6 bug */
if (res.attr_bitmask[0] & FATTR4_WORD0_FS_LOCATIONS && minorversion >= 2)
server->caps |= NFS_CAP_FS_LOCATIONS;
in nfs4proc.c does the trick for me.
]]>I guess if server->caps should just be "0", that would have been there all along.
idk whether or which caps need to go at this point, but this one's tested when the connection fails and since that's an error, I assume at least this capability must not bleed into the server caps.
First, let's see whether it's relevant at all
Yeah, unfortunately, it did not help ...
It seems that the knfsd from Qnap (kernel 3.4.6) does misreport support for FS_LOCATIONS.
Next attempt will be to disallow FS_LOCATIONS for NFS <= v4.1.
https://git.kernel.org/pub/scm/linux/ke … oc.c#n3859 clears a bunch of caps before parsing them - what if you keep the offending patch but first remove the cap there as well, ie.
server->caps &= ~(NFS_CAP_ACLS | NFS_CAP_HARDLINKS | NFS_CAP_SYMLINKS| NFS_CAP_SECURITY_LABEL|NFS_CAP_FS_LOCATIONS);
?
Good spotting, test compilation is running ...
Being at it, shouldn't we clear a bunch more fields?
I see at least: NFS_CAP_CASE_PRESERVING | NFS_CAP_CASE_INSENSITIVE
Or, to code this more defensively: Do we know of a finite, not evolving set of flags that might need to be preserved and just clear all other bits to be on the safe side when the set of caps is extended the next time?
server->caps &= ~(NFS_CAP_ACLS | NFS_CAP_HARDLINKS |
NFS_CAP_SYMLINKS| NFS_CAP_SECURITY_LABEL|NFS_CAP_FS_LOCATIONS);
?
]]>A comment was the right way to do it, but being an upstream kernel issue, it's unlikely anything will happen with that bug report. Someone needs to bisect (there are more than a dozen NFS related commits in this release) and report it upstream.
Done. I have bisected this to be caused by commit 6f283634 (in 5.15.24).
I have sent an eMail to Olga (and copied linux-nfs@vger).
The problem here happens against Qnap (all exports, NFS v4.1, Qnap 4.3.4-XXX) but not 5.15 knfsd.
As You can see I am using "vers=3"
And you are so right! Changing the variable in /etc/nfsmount.conf into version 3 as preferred (and allowing v3 in server) it does work again. Thanks for this valuable addition!
]]> $ showmount --exports 192.168.1.5 -e
Export list for 192.168.1.5:
/mnt/HD_a2 192.168.1.0/24
$ sudo mount -o rw,vers=3 -t nfs 192.168.1.5:/mnt/HD_a2 /home/v/MNT/NFS/5
Created symlink /run/systemd/system/remote-fs.target.wants/rpc-statd.service → /usr/lib/systemd/system/rpc-statd.service.
As You can see I am using "vers=3"
]]>