Re: Linux 5.11 Kernel: NFS re-export errors with older nfs-utils package versions

[Benjamin Maynard <benmaynard@google.com>]

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?

It looks like the Wiki is locked down to registered collaborators
otherwise I would add it myself.

Kind regards
Benjamin Maynard


On Thu, 21 Jan 2021 at 15:37, J. Bruce Fields <bfields@fieldses.org> 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.