On Fri, 2026-01-16 at 15:46 +0100, Amir Goldstein wrote:
> On Fri, Jan 16, 2026 at 1:36 PM Jeff Layton <[email protected]> wrote:
> >
> > On Thu, 2026-01-15 at 20:23 +0100, Amir Goldstein wrote:
> > > On Thu, Jan 15, 2026 at 6:51 PM Jeff Layton <[email protected]> wrote:
> > > >
> > > > Some filesystems have grown export operations in order to provide
> > > > filehandles for local usage. Some of these filesystems are unsuitable
> > > > for use with nfsd, since their filehandles are not persistent across
> > > > reboots.
> > > >
> > > > In __fh_verify, check whether EXPORT_OP_STABLE_HANDLES is set
> > > > and return nfserr_stale if it isn't.
> > > >
> > > > Signed-off-by: Jeff Layton <[email protected]>
> > > > ---
> > > > fs/nfsd/nfsfh.c | 4 ++++
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> > > > index
> > > > ed85dd43da18e6d4c4667ff14dc035f2eacff1d6..da9d5fb2e6613c2707195da2e8678b3fcb3d444d
> > > > 100644
> > > > --- a/fs/nfsd/nfsfh.c
> > > > +++ b/fs/nfsd/nfsfh.c
> > > > @@ -334,6 +334,10 @@ __fh_verify(struct svc_rqst *rqstp,
> > > > dentry = fhp->fh_dentry;
> > > > exp = fhp->fh_export;
> > > >
> > > > + error = nfserr_stale;
> > > > + if (!(dentry->d_sb->s_export_op->flags &
> > > > EXPORT_OP_STABLE_HANDLES))
> > > > + goto out;
> > > > +
> > > > trace_nfsd_fh_verify(rqstp, fhp, type, access);
> > > >
> > >
> > > IDGI. Don't you want to deny the export of those fs in check_export()?
> > > By the same logic that check_export() checks for can_decode_fh()
> > > not for can_encode_fh().
> > >
> >
> > It certainly won't hurt to add a check for this to check_export(), and
> > I've gone ahead and done so. To be clear, doing that won't prevent the
> > filesystem from being exported, but you will get a warning like this
> > when you try:
> >
> > exportfs: /sys/fs/cgroup does not support NFS export
> >
> > That export will still show up in mountd though, so this is just a
> > warning. Trying to mount it though will fail.
> >
>
> Oh, I did not know. What an odd user experience.
> Anyway, better than no warning at all.
>
Indeed.
The catch is that this won't catch all scenarios where that fs could be
exported. If you do something like this in /etc/exports:
/ *(rw,crossmnt,insecure,no_root_squash)
...you won't see a warning. Granted, doing the above is _dumb_ but it
illustrates that it's not possible to completely vet the export table.
Even if you could, it could change out from under you.
We do have some ideas about updating the export management, but nothing
concrete yet. Even then, we'll need to maintain backward compatibility,
so I doubt we can change the user experience in a fundamental way at
this point.
--
Jeff Layton <[email protected]>
