Technical

Container mount point GID mapping works, but no write access

Container mount point GID mapping works, but no write access

Container mount point GID mapping works, but no write access. Annoying as hell. The mapping shows up correctly in the container, but every write fails with permission denied. Here’s the fix path that actually works.

Close-up of an orange portable hard drive on a wooden table, perfect for tech and business themes.

First, check the host directory owner

This is the one everyone skips. The host directory you bind-mount must be owned by the mapped GID on the host. If your container user is uid 1000 mapped to host uid 100000, then the host folder needs to be owned by 100000. Not root, not your normal user. Run this on the host:

stat -c '%u %g %n' /path/on/host

If the GID isn’t what you mapped, chown it:

chown -R 100000:100000 /path/on/host

Yes, that number looks weird. It’s the subuid/subgid offset, and it has to match exactly.

Then look at ACLs

Even with correct ownership, default ACLs on the host directory can block writes. Check with:

getfacl /path/on/host

If you see anything other than the basic user/group/other entries, strip them:

setfacl -b /path/on/host

ACLs are a pain in the butt and rarely needed for simple bind mounts. Get rid of them.

Internal view of a hard disk drive revealing its disk platter and read/write head for data storage.

The map order matters

In your container config, the idmap entries are order-sensitive. The first matching rule wins. If you have a broad rule like u 0 100000 65536 before a more specific one for your user, the broad rule eats it. Put the specific mapping first:

lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535

That maps uid/gid 1000 in the container to 1000 on the host, and everything else to the offset range. If the order is reversed, the specific mapping never applies.

Test it properly

Inside the container, don’t just try to create a file. Check what the container actually sees:

id
ls -ld /mount/point
touch /mount/point/testfile

If id shows the right uid/gid, and ls -ld shows the right owner, but touch still fails, it’s almost always an ACL or the host directory is mounted read-only. Check the mount options in the container config too — ro will ruin your day.

This is the same kind of UID/GID nonsense that bites people with SMB mounts in LXC. The mapping looks fine, but the underlying ownership doesn’t line up.

My take

Don’t overthink it. For a homelab, just chown the host directory to the offset GID and strip the ACLs. That fixes 90% of these cases. If you need more granular permissions, use a separate bind mount per user instead of fighting the idmap.

Leave a comment

Comments are reviewed before they appear. Your email is never published.