Debugging mount.nfs: Operation not permitted

I’m getting the mount.nfs operation not permitted error, but there’s nothing logged in the syslog of either the host or container about it to help me further. I’m specifically looking for a DENIED apparmor entry and it’s nowhere to be found. The only log entry is
mount: /proc/fs/nfsd: permission denied.

Running ubuntu 22.04 on both host and container, LXC versions
Client version: 5.3
Server version: 5.3

lxc config show mrx

architecture: x86_64
  image.architecture: amd64
  image.description: Ubuntu focal amd64 (20220319_07:42)
  image.os: Ubuntu
  image.release: focal
  image.serial: "20220319_07:42"
  image.type: squashfs
  image.variant: default
  limits.cpu: "2"
  limits.memory: 8GB
  limits.processes: "500"
  raw.apparmor: mount fstype=nfs*,mount fstype=rpc_pipefs,
  security.nesting: "true"
  security.privileged: "false"
  volatile.base_image: 4d6bf4de0e5d64374733ccd48ef626b3a2d9cdd2c136a74baa55986d3782fbae
  volatile.eth0.host_name: veth56bbb549
  volatile.eth0.hwaddr: 00:16:3e:88:a7:06
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":tru
e,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]' '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":
  volatile.last_state.power: RUNNING
  volatile.uuid: d244ea5c-0f45-4842-9547-14e0779199c0
    path: /
    pool: default
    size: 30GB
    type: disk
ephemeral: false

I’ve also tried
lxc config set mrx raw.lxc “lxc.apparmor.profile=lxc-container-default-with-nfs”
but this broke the docker daemon running inside that lxc.

What’s the best suggestion, I don’t want to swap to unprivileged just because of some read only nfs mounts.

NFS cannot be used in unprivileged containers.

1 Like

Thanks. I got some conflicting information from other sources then with the apparmor workarounds.
I will resort to using a bind mount device from the host then.

So, it seems that security.privileged=true and security.nested=true (see apparmor="DENIED" operation="mount" - #10 by Andrew_Wilson) are required to be able to mount NFS in a container.

@stgraber, can you please expand on the motivation? did the scenario change since then?

NFS isn’t supported for mounting inside of user namespaces.
This is a Linux kernel limitation and I’m not currently aware of anyone working on changing that.

I believe it’s possible to workaround some of that inside of an unprivileged container by using some of the security.syscalls.intercept.mount options. But you’ll need a kernel with shiftfs support to make this work in any useful way.

Note that an alternative would be to use a FUSE implementation of NFS. I believe there is a NFSv3 implementation of it somewhere.

Hours trying to fix this, and you nailed it, i was using unpriviledged container, thanks for the help