On Thu, Jan 21, 2021 at 05:46:31PM +0000, Benjamin Maynard wrote: > That makes sense, and thanks for explaining. > > Seeing as the error message does not immediately point to an outdated > nfs-utils version would we be able to add a note to the Wiki > (http://wiki.linux-nfs.org/wiki/index.php/NFS_re-export) to help > others that may come across this issue? Yep, done. > It looks like the Wiki is locked down to registered collaborators > otherwise I would add it myself. The log in page has a link to the form to request an account. I think those requests are routinely granted, it's just there to deal with spam. --b. > > Kind regards > Benjamin Maynard > > > On Thu, 21 Jan 2021 at 15:37, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > On Thu, Jan 21, 2021 at 11:21:56AM +0000, Benjamin Maynard wrote: > > > That is correct, there is an originating NFS Server (Ubuntu 20.04 - > > > 5.4.0-1034-gcp) that is exporting a directory from the local ext4 > > > filesystem. This is exported with the following options: > > > > > > /files 10.0.0.0/8(rw,no_subtree_check,fsid=10) > > > > > > This is then mounted from the re-exporting server (export from /proc/mounts): > > > > > > 10.70.1.2:/files /files nfs > > > rw,sync,noatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,acregmin=600,acregmax=600,acdirmin=600,acdirmax=600,hard,nocto,proto=tcp,nconnect=16,timeo=600,retrans=2,sec=sys,mountaddr=10.70.1.2,mountvers=3,mountport=20048,mountproto=udp,fsc,local_lock=none,addr=10.70.1.2 > > > 0 0 > > > > > > We then attempt to re-export the mounted directory from the > > > re-exporting server with the following entry in /etc/exports: > > > > > > /files 10.67.0.0/16(rw,wdelay,no_root_squash,no_subtree_check,fsid=10,sec=sys,rw,secure,no_root_squash,no_all_squash) > > > > > > If you perform this set of steps with the 5.10 kernel with nfs-utils > > > 1.3.4 (Ubuntu & Debian default version), the re-export will work. If > > > you perform the same set of steps with the ba5e8187c555 patch applied > > > (still on nfs-utils 1.3.4) then the re-export will fail with the error > > > message "exportfs: /files does not support NFS export". dmesg further > > > reveals the cause "check_export: nfs does not support subtree > > > checking!". > > > > > > This message appears even though we have no_subtree_check set on both > > > the exports of the originating NFS server, and the re-export server. > > > > > > If you then upgrade nfs-utils to 2.5.2 on the re-export server, the > > > re-export works as expected. > > > > Oh, got it, looks like the bug fixed by nfs-utils commit 63f520e8f6f5 > > "exportfs: Make sure pass all valid export flags to nfsd". > > > > Rough explanation: export information isn't normally passed down to the > > kernel when exportfs is called. Instead the kernel waits till it needs > > to know about some new client and/or filesystem and calls up to mountd > > to ask for the relevant export entry. > > > > Anyway, that's fine but it means the user doesn't find about errors > > right away. > > > > So, trying to be helpful, exportfs actually does pass down a dummy > > export to the kernel at exportfs time, just to check for errors like a > > typo'd export path or an unexportable filesystem. > > > > Before that fix, it passed down that dumy export without the > > "no_subtree_check" flag, even when you set that flag. > > > > So, for nfs reexport, you need an nfs-utils new enough to include that > > patch. > > > > We're normally pretty strict about kernel regressions: if something > > stopped working on kernel upgrade, that's a bug. But I think we really > > do need to fail attempts to re-export NFS with subtree checking, so > > we've got to make an exception here. Re-export is still a bit of an > > experimental feature, so there may be hiccups like this. > > > > --b.
