Why an unprivileged LXC can read a network share but not write to it

This one is maddening because the permissions look correct from both sides. Inside the container, everything is owned by root. On the host, the mount is owned by root. And yet writes fail, or worse — they appear to work and the file lands somewhere unexpected.

Why it happens

An unprivileged container does not run its root as your host's root. Proxmox maps it to an unprivileged range, conventionally starting at UID 100000. So:

• root inside the container = UID 100000 on the host
• a host-side NFS or CIFS mount is typically owned by UID 0
• UID 100000 is not UID 0, so the container cannot write to it

Reading often still works, which is the confusing part — many exports are world-readable. So the share looks mounted and healthy right up until something tries to write.

The fix that actually works

Mount on the host with the container's UID written into the mount options, then bind-mount it into the container:

# on the HOST, in /etc/fstab
//192.168.1.10/media  /mnt/media  cifs   credentials=/root/.smbcred,uid=100000,gid=100000,file_mode=0664,dir_mode=0775,nofail  0 0

# on the HOST
mount /mnt/media

# in the container config (/etc/pve/lxc/<vmid>.conf)
mp0: /mnt/media,mp=/mnt/media,ro=0

Now the host filesystem presents the files as owned by UID 100000, which is exactly what the container's root maps to. Writes work.

NFS is harder than CIFS here. Root squash compounds the problem: the server remaps UID 0 to an anonymous user, and the UID you carefully set on the client may not be honoured the same way. Where you have the choice, CIFS with explicit uid=/gid= is the more predictable path.

Verify it from the right side

Do not verify by creating a file on the host — that proves nothing about the container's mapping. Write from inside the container:

pct exec <vmid> -- touch /mnt/media/.write-test
pct exec <vmid> -- ls -ln /mnt/media/.write-test   # check the owning UID

Then restart the container and check again. A bind mount that works until a restart is not fixed, and this class of bug loves to reappear after a reboot.

The same trap with a different face

UID mapping bites in less obvious places too. A service that serves files from a bind-mounted directory may fail to read them because the file has no world-read bit and the serving process is not the mapped user. The symptom is silent: the service starts, reports healthy, and serves an empty or broken result.

The tell is always the same — an operation that works as your host root and fails as anything else. When that happens, stop looking at the container's permissions and check the UID the container's root actually maps to on the host.

← All writing