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.
