Debugging mount.nfs: Operation not permitted

LXD
1

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
config:
  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}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"
Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":
true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.power: RUNNING
  volatile.uuid: d244ea5c-0f45-4842-9547-14e0779199c0
devices:
  root:
    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.

2

NFS cannot be used in unprivileged containers.

1 Like
3

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.

4

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?

5

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.

6

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.

7

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