Proxmox bind mounts are a nightmare for user permissions

Decronym Bot , 23 days ago

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

Fewer Letters	More Letters
LXC	Linux Containers
NFS	Network File System, a Unix-based file-sharing protocol known for performance and efficiency
RAID	Redundant Array of Independent Disks for mass storage

---

[Thread #882 for this sub, first seen 24th Jul 2024, 09:45] [FAQ] [Full list] [Contact] [Source code]

gaylord_fartmaster , 30 days ago

The issue is that the docker container will still be running as the LXC’s root user even if you specify another user to run as in the docker compose file or run command, and if root doesn’t have access to the dir the container will always fail.

The solution to this is to remap the unprivileged LXC’s root user to a user on the Proxmox host that has access to the dir using the LXC’s config file, mount the container’s filesystem using pct mount, and then chown everything in the container owned by the default root mapped user (100000).

These are the commands I use for this:

<span style="color:#323232;">find /var/lib/lxc/xxx/rootfs -user 100000 -type f -exec chown username {} +;
</span><span style="color:#323232;">find /var/lib/lxc/xxx/rootfs -user 100000 -type d -exec chown username {} +;
</span><span style="color:#323232;">find /var/lib/lxc/xxx/rootfs -user 100000 -type l -exec chown -h username {} +;
</span><span style="color:#323232;">find /var/lib/lxc/xxx/rootfs -group 100000 -type f -exec chown :username {} +;
</span><span style="color:#323232;">find /var/lib/lxc/xxx/rootfs -group 100000 -type d -exec chown :username {} +;
</span><span style="color:#323232;">find /var/lib/lxc/xxx/rootfs -group 100000 -type l -exec chown -h :username {} +
</span>

(Replace xxx with the LXC number and username with the host user/UID)

If group permissions are involved you’ll also have to map those groups in the LXC config, create them in the LXC with the corresponding GIDs, add them as supplementary groups to the root user in the LXC, and then add them to the docker compose yaml using group_add.

It’s super confusing and annoying but this is the workflow I’m using now to avoid having to have any resources tied up in VMs unnecessarily.

Eideen , 30 days ago

It is not 1000 it 10000.

You can try with setting g+w on pve.

ama_coffee_addict OP , 30 days ago

It is 100000 actually and even with 777 rights it still fails.

glizzyguzzler , 30 days ago

In incus, I had the same setup of an LCX container with a Docker container inside of it. I passed 1000/1000 to the LXC container but the LXC container’s default root user has a an ID set of 0/0. So I had to pass 0/0 to the Docker container, not 1000/1000 to get the read/write permissions working.

That may fix your issue as it’s basically the same tech, just different automated things implementing the LXC container!

anon_8675309 , 30 days ago

So I don’t use docker. But. Could you set up an lxc container running samba and then bind mount the shares to that container. Then mount those shares inside docker running on the other lxc container?

ama_coffee_addict OP , 30 days ago

That sounds a bit too convoluted for my needs. Even if it works, I am not sure if I will be able to maintain such a setup. But thanks for your inputs.

scrubbles , 30 days ago

I’ll be honest man, just don’t do it. I tried, I really did, to make this exact scenario to work. You can get it to work - but it will be extremely brittle. You’re essentially hacking around LXC to do things it wasn’t built to do, and most of it is disabling security that’s there for a reason. At the end of the day you are essentially running docker directly on the host anyway, the passthrough lxc becomes less and less “there” vs passing stuff through. Then, every update to proxmox became anxiety riddled because every update would change or break something on my setup.

If you want to continue, more power to you, but I hope you heed my warnings. This is a path you will spend a lot of time on and experience a lot of frustration. Spin up a tiny debian VM and run the containers there, the overhead of the VM has been negligible, and any speedup I might have had has been made up 10x by cutting the amount of time I’ve had to hack proxmox to make it work.

ama_coffee_addict OP , 30 days ago

I might have to heed to your warnings. The nfs share is actually a mirror RAID hosted on an OMV VM on the same host. It would be just easier to spin up bookstack image on that VM itself. Thanks

skittlebrau , 30 days ago

Sage advice.

I went through the same thing and eventually reached the conclusion that a VM really is the best method. I did get a working LXC Docker setup going, but I could just not get it to be as stable as a VM long-term.

revv , 30 days ago

I’m not a docker expert- i tend to just run everything in an LXC. But, doesn’t docker typically run as root? It might be that you gave your lxc user UID proper permissions, but not the lxc root UID.

Alternatively, you are aware that LXC UID 1000 != Host UID 1000, yes?

FWIW, permissions in proxmox/LXC are really clear and predictable… once you understand the way the map in the config files.

scrubbles , 30 days ago

the default is root, but most containers will specify a UID/GID to run under. That makes it even harder with docker on lxc on proxmox.

ama_coffee_addict OP , 30 days ago

This is the case with bookstack image. I specify the uid and gid as environment variables and it is expected that the ids remain compatible with the lxc and the host. But I am having trouble writing to the mount even from the lxc with the uid 1000 which is mapped to 101000 on the host.