crossmnt exports partially broken in 7.2?

crossmnt exports partially broken in 7.2?

[Mantas Mikulėnas]

Hello,

After upgrading an NFS server to kernel 7.2.2 (from 7.1.11), it is no longer
possible to mount filesystems that should be handled by a "crossmnt" export.

For example, with /etc/exports being:

         /       *(rw,crossmnt,sec=krb5:krb5i:krb5p)

and all clients using NFSv4.2, it used to be possible to either mount 
foo:/hdd2
directly, or to descend into it through a "foo:/" mount.

With kernel 7.2 this no longer works -- after mounting foo:/hdd2 all 
attempts
to access it result in -ESTALE and the client's kernel complains about 
"fileid
changed":

         # mount horizon:/hdd1 /mnt

         # ls -l /mnt
         ls: cannot open directory '/mnt': Stale file handle

         # dmesg | tail -2
         [374226.359731] NFS: server horizon error: fileid changed
                         fsid 0:150: expected fileid 0x2, got 0x100

Mounting "foo:/" on /mnt and trying to stat /mnt/hdd1 likewise returns 
-ESTALE.
(Or hangs for a while if it's a autofs mount on the server side, but I 
switched
from systemd.automount to regular non-autofs mounts for now.)

In this case the server's root filesystem is Btrfs, additional disks are 
Ext4.
Another system with the same problem has Btrfs for both the rootfs and 
for the
secondary disks.

Bisect points to commit 70b7e3526c53d9dd7caccdbeff5b0485640d8cf1 which 
adds a
netlink interface for nfs-utils' rpc.mountd to use. Indeed if I disable 
netlink
support there (adding "[mountd] no-netlink=1" to the server's /etc/nfs.conf)
then crossmnt exports again start working as they should, even with 
kernel 7.2.
I've also tried kernel 7.3-rc1 with the same results.

Does this look like a kernel bug, or a nfs-utils (rpc.mountd) bug, or both?
The server has nfs-utils 2.9.2.

Re: crossmnt exports partially broken in 7.2?

[Jeff Layton]

On Mon, 2026-09-07 at 14:33 +0300, Mantas Mikulėnas wrote:
> Hello,
> 
> After upgrading an NFS server to kernel 7.2.2 (from 7.1.11), it is no longer
> possible to mount filesystems that should be handled by a "crossmnt" export.
> 
> For example, with /etc/exports being:
> 
>          /       *(rw,crossmnt,sec=krb5:krb5i:krb5p)
> 
> and all clients using NFSv4.2, it used to be possible to either mount 
> foo:/hdd2
> directly, or to descend into it through a "foo:/" mount.
> 
> With kernel 7.2 this no longer works -- after mounting foo:/hdd2 all 
> attempts
> to access it result in -ESTALE and the client's kernel complains about 
> "fileid
> changed":
> 
>          # mount horizon:/hdd1 /mnt
> 
>          # ls -l /mnt
>          ls: cannot open directory '/mnt': Stale file handle
> 
>          # dmesg | tail -2
>          [374226.359731] NFS: server horizon error: fileid changed
>                          fsid 0:150: expected fileid 0x2, got 0x100
> 
> Mounting "foo:/" on /mnt and trying to stat /mnt/hdd1 likewise returns 
> -ESTALE.
> (Or hangs for a while if it's a autofs mount on the server side, but I 
> switched
> from systemd.automount to regular non-autofs mounts for now.)
> 
> In this case the server's root filesystem is Btrfs, additional disks are 
> Ext4.
> Another system with the same problem has Btrfs for both the rootfs and 
> for the
> secondary disks.
> 
> Bisect points to commit 70b7e3526c53d9dd7caccdbeff5b0485640d8cf1 which 
> adds a
> netlink interface for nfs-utils' rpc.mountd to use. Indeed if I disable 
> netlink
> support there (adding "[mountd] no-netlink=1" to the server's /etc/nfs.conf)
> then crossmnt exports again start working as they should, even with 
> kernel 7.2.
> I've also tried kernel 7.3-rc1 with the same results.
> 
> Does this look like a kernel bug, or a nfs-utils (rpc.mountd) bug, or both?
> The server has nfs-utils 2.9.2.
> 

It's an nfs-utils bug (I think), though I'm still confirming that. I
had Claude draft some patches, but they're still quite raw. If you're
interested in testing them, they're in my nl-crossmnt branch on github:

    https://github.com/jtlayton/nfs-utils/tree/nl-crossmnt

Thanks for the bug report!
-- 
Jeff Layton <jlayton@kernel.org>