Running NFS kernel server inside Incus container

Incus
1

Hi,

I am running a NFS kernel server inside a (privileged) Incus container, based on Debian containers. Up to Debian 12, things worked fine, but I find that when migrating to Debian 13, they stop working. I debugged it to the point where it seems that mounting the nfsd filesystem inside the container is prevented by apparmor, even when I have allowed mounting fstype=nfsd for that container.

Here is how to reproduce it:

Incus configuration for running kernel nfsserver inside container:

# incus profile show nfs

config:
raw.apparmor: mount fstype=rpc_pipefs, mount fstype=nfsd,
security.privileged: “true”
description: Configuration for kernel NFS server.
devices: {}
name: nfs
used_by:

  • /1.0/instances/generic-nfs-13
  • /1.0/instances/generic-nfs-12
    project: default

Debian 12:

# incus launch images:debian/12 generic-nfs-12

# incus profile add generic-nfs-12 nfs

# incus exec generic-nfs-12 apt -y install nfs-kernel-server

# incus exec generic-nfs-12 – showmount -e localhost

Export list for localhost:

Success!

Debian 13:

# incus launch images:debian/13 generic-nfs-13

# incus profile add generic-nfs-13 nfs

# incus exec generic-nfs-13 apt -y install nfs-kernel-server

# incus exec generic-nfs-13 – showmount -e localhost

clnt_create: RPC: Program not registered

Failure!

# incus exec generic-nfs-13 – /bin/bash -l

root@generic-nfs-13:~# mount -t nfsd nfsd /proc/fs/nfsd
mount: /proc/fs/nfsd: nfsd already mounted or mount point busy.
dmesg(1) may have more information after failed mount system call.

dmesg shows this error message:
[73099.511111] audit: type=1400 audit(1768135248.999:496): apparmor=“DENIED” operation=“mount” class=“mount” info=“failed type match” error=-13 profile=“incus-generic-nfs-13_</var/lib/incus>” name=“/proc/fs/nfsd/” pid=154101 comm=“mount” flags=“rw, move”

So, it looks like the same raw.apparmor config “mount fstype=nfsd” allows mounting the nfsd configuration filesystem in a Debian 12 container, but not in a Debian 13 container. This seems to be odd.

Can anyone give me a hint on how to change the Incus apparmor configuration line in order to allow mounting the nfsd filesystem in a Debian 13 container?

2

Note that the AppArmor failure isn’t about mounting the filesystem but moving it to a particular path (rw, move).

This could be because something is actually mounting it in one location and then moving it, or maybe more likely, because something was ported to the new kernel mount API which apparmor gets very confused about.

3

Some more research reveals that the difference that matters is a more modern version of util-linux (v2.41) in Debian 13 that uses different kernel calls to do the mount. While the old util-linux used the one-shot mount() call, the newer util-linux uses the more sophisticated calls, see e.g.

strace shows that it is the move_mount() system call that fails with an EACCES error. I thought that this is represented by a mount option ‘move’ and that a raw.apparmor rule
mount fstype=nfsd options=(rw,move),
should do the trick. But when adding that to the config of the Incus container, I get the error message from Incus: ‘encoding of mount rule failed’. This error message is specific to giving the mount option ‘move’ and doesn’t occur with any other mount option I would specify.

Just for the record: when allowing any mount with
raw.apparmor: mount,
I can make it work. But maybe someone in the know of how mount rules are encoded by Incus could help to specify the required system calls more specific?

4

Thank you Stephane, our messages crossed. Yes, it is the new kernel API kernel for mounting. Maybe it is possible to allow that specific API call needed?

5

Sadly not, AppArmor has no support for mediation of the new kernel API and basically just blocks it all…

You can try this trick:

printf "2\ndenylist\nreject_force_umount\n[all]\nfsconfig errno 38\nfsopen errno 38\n" | incus config set NAME raw.seccomp -

It basically uses Seccomp to block the new system calls, forcing the system to use the older legacy system calls instead.