Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CA+QRt4vb=DjgcOqGLtfdfKiDaqKED825xNpNyQaaK-df5tCSRQ@mail.gmail.com>
 <20210119180204.GA24213@fieldses.org> <CA+QRt4sxwMTTWpropg=O=XdJ42P+2H=jbrwC8E1n=gt+je6iXQ@mail.gmail.com>
 <20210121153709.GA18310@fieldses.org>
In-Reply-To: <20210121153709.GA18310@fieldses.org>
From:   Benjamin Maynard <benmaynard@google.com>
Date:   Thu, 21 Jan 2021 17:46:31 +0000
Message-ID: <CA+QRt4u8eAX6F7RuR-yORULCatrEJdorZbKKDnDHZAPx+Y=wUA@mail.gmail.com>
Subject: Re: Linux 5.11 Kernel: NFS re-export errors with older nfs-utils
 package versions
To:     "J. Bruce Fields" <bfields@fieldses.org>
Cc:     linux-nfs@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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=3D10)
> >
> > This is then mounted from the re-exporting server (export from /proc/mo=
unts):
> >
> > 10.70.1.2:/files /files nfs
> > rw,sync,noatime,vers=3D3,rsize=3D1048576,wsize=3D1048576,namlen=3D255,a=
cregmin=3D600,acregmax=3D600,acdirmin=3D600,acdirmax=3D600,hard,nocto,proto=
=3Dtcp,nconnect=3D16,timeo=3D600,retrans=3D2,sec=3Dsys,mountaddr=3D10.70.1.=
2,mountvers=3D3,mountport=3D20048,mountproto=3Dudp,fsc,local_lock=3Dnone,ad=
dr=3D10.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=3D=
10,sec=3Dsys,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.