Mount host directory into LXC container with specific UIDs/GIDs

G

gannick

Member
Sep 2, 2022
24
0
6
Hello everyone,

I am new on Proxmox. I installed it last week after tips from a colleague. I previously used LXC via LXD on a stock Debian. So I am not totaly a newbie about container. On my previous installation, I shared a host directory with a Nextcloud LXC container. The goal is to backup the data from the host and from a separate physical disk than the OS and containers disk. It worked on LXC/LXD.

Yesterday, I tried to do the same on Proxmox. I followed :
https://forum.proxmox.com/threads/mount-host-directory-into-lxc-container.66555/
https://pve.proxmox.com/wiki/Unprivileged_LXC_containers#Using_local_directory_bind_mount_points

I succesfully had the mount point betwee, host and LXC container, no problem on that.

But the UID/GID mapping failed, and so the LXC container did not reboot. I had to suppress my configuration to have the container booting.

What I would like to have is :
HostContainer
Mount point/data/data_nextcloud/var/data_nextcloud
Mount point owneruser with UID 1000 GID 1000www-data with UID 33 GID 33

I tried a lot of things in the file /etc/pve/lxc/101.conf, such as
Code: 
# uid map: from uid 0 map 1005 uids (in the ct) to the range starting 100000 (on the host), so 0..1004 (ct) → 100000..101004 (host)
lxc.idmap = u 0 100000 33
lxc.idmap = g 0 100000 33
# we map 1 uid starting from uid 1005 onto 1005, so 1005 → 1005
lxc.idmap = u 1000 33 1
lxc.idmap = g 1000 33 1
# we map the rest of 65535 from 1006 upto 101006, so 1006..65535 → 101006..165535
lxc.idmap = u 34 101006 64530
lxc.idmap = g 34 101006 64530

I am also pretty lost with files subuid and subgid, and tried to comment the root line to put my_host_user:1000:1

Any help to really understand what's wrong and what I must did will be appreciate. Thanks by advance.
 
I found this useful script on the internet and it suggest the following for mapping Host user/group ID 1000 to Container user/group ID 33:
lxc.idmap: u 0 100000 1000 lxc.idmap: g 0 100000 1000 lxc.idmap: u 1000 33 1 lxc.idmap: g 1000 33 1 lxc.idmap: u 1001 101001 64535 lxc.idmap: g 1001 101001 64535
And you might need to adjust /etc/subuid and /etc/subgid.
 
leesteken said:
I found this useful script on the internet and it suggest the following for mapping Host user/group ID 1000 to Container user/group ID 33:
lxc.idmap: u 0 100000 1000 lxc.idmap: g 0 100000 1000 lxc.idmap: u 1000 33 1 lxc.idmap: g 1000 33 1 lxc.idmap: u 1001 101001 64535 lxc.idmap: g 1001 101001 64535
And you might need to adjust /etc/subuid and /etc/subgid.
Click to expand...
Thanks @leesteken for your answer, I will try tonight. In the subuid and subgid, I must put this ?
Code: 
root:100000:65536
root:1000:1

And not the name of my system user UID 1000 ?
 
Fail...

lxc_map_ids: 3672 newuidmap failed to write mapping "newuidmap: uid range [1000-1001) -> [33-34) not allowed": newuidmap 1316764 0 100000 1000 1000 33 1 1001 101001 64535 lxc_spawn: 1791 Failed to set up id mapping.

My /etc/pve/lxc/101.conf :
Code: 
arch: amd64
cores: 1
features: nesting=1
hostname: nextcloud
memory: 1024
mp0: /data/data_nextcloud/,mp=/var/data_nextcloud
nameserver: 192.168.1.254
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.254,hwaddr=B2:A7:1E:5D:B7:28,ip=192.168.1.237/24,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-101-disk-0,size=8G
swap: 512
unprivileged: 1
lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 33 1
lxc.idmap: g 1000 33 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535

And subuid and subgid :
Code: 
root:100000:65536
root:1000:1

Any idea why the reboot is failing ?
 
gannick said:
lxc_map_ids: 3672 newuidmap failed to write mapping "newuidmap: uid range [1000-1001) -> [33-34) not allowed": newuidmap 1316764 0 100000 1000 1000 33 1 1001 101001 64535 lxc_spawn: 1791 Failed to set up id mapping.

And subuid and subgid :
root:100000:65536 root:1000:1

Any idea why the reboot is failing ?
Click to expand...
You typically get this kind of error when /etc/subuid is not correct, but it appears to be correct (as per the website tool and my own experiences).
 
I tried to put the user www-data on both side :
mp0: /data/data_nextcloud/,mp=/var/test lxc.idmap: u 0 100000 33 lxc.idmap: g 0 100000 33 lxc.idmap: u 33 33 1 lxc.idmap: g 33 33 1 lxc.idmap: u 34 100034 65502 lxc.idmap: g 34 100034 65502 root:100000:65536 root:33:1

Container restarted, and UID/GID are ok on both side (I forgot to do chown 33:33 on host side).

I tried something I found more logical :
mp0: /data/data_nextcloud/,mp=/var/test lxc.idmap: u 0 100000 33 lxc.idmap: g 0 100000 33 lxc.idmap: u 1000 100033 1 lxc.idmap: g 1000 100033 1 lxc.idmap: u 1001 100034 65502 lxc.idmap: g 1001 100034 65502 root:100000:65536 root:1000:1

root:100000:65536
root:33:1
[/ICODE]

Container restarted, but in the container :
drwxr-xr-x 2 nobody nogroup 4096 Sep 1 19:44 test

So, still not really working...

I tried on both side with the same user ID : 1000. That works...

The conf :
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

Any idea ? I would prefer to have a none special user on host to own data for backup... Maybe an issue with ID >= 1000 on host side and ID < 1000 on container ?
 
Last edited:
gannick said:
I tried to put the user www-data on both side :
mp0: /data/data_nextcloud/,mp=/var/test lxc.idmap: u 0 100000 33 lxc.idmap: g 0 100000 33 lxc.idmap: u 33 33 1 lxc.idmap: g 33 33 1 lxc.idmap: u 34 100034 65502 lxc.idmap: g 34 100034 65502 root:100000:65536 root:33:1

Container restarted, but in the container :
drwxr-xr-x 2 nobody nogroup 4096 Sep 1 19:44 test
Click to expand...
Don't forget to chown -R 33:33 /data/data_nextcloud/ the folder you want to bind-mount to UID 33 in case its not owned by UID 33 on the host. When that folder isn't owned by UID/GID 33 you will see a "nobody nogroup" as owner inside the LXC.
mp0: /data/data_nextcloud/,mp=/var/test lxc.idmap: u 0 100000 33 lxc.idmap: g 0 100000 33 lxc.idmap: u 1000 100033 1 lxc.idmap: g 1000 100033 1 lxc.idmap: u 1001 100034 65502 lxc.idmap: g 1001 100034 65502 root:100000:65536 root:1000:1 root:100000:65536 root:33:1
Click to expand...
That mapping makes no sense. It will map 0-32 to 10000-100032, 1000 to 100033, 1001-65501 to 100034-65535. It won't map 33-999 or 65502-65535. You have to map the full 0 to 65535 range.
 
Last edited:
Dunuin said:
Don't forget to chown -R 33:33 /data/data_nextcloud/ the folder you want to bind-mount to UID 33 in case its not owned by UID 33 on the host. When that folder isn't owned by UID/GID 33 you will see a "nobody nogroup" as owner inside the LXC.

That mapping makes no sense. It will map 0-32 to 10000-100032, 1000 to 100033, 1001-65501 to 100034-65535. It won't map 33-999 or 65502-65535. You have to map the full 0 to 65535 range.
Click to expand...
It works with 33:33 on both side. But it was not really what I wanter. I wanted user 1000 on host (chown 1000) and 33 on container. That doesn't work, the container is not loading in that case. As I say before, what I wanted to do was working with LXD/LXC...

But I also have a strange effect, the directory /var/www/nextcloud is now owned by nobody:nogroup and I have never touch to him. Root is not capable to chown this directory.
 
gannick said:
But I also have a strange effect, the directory /var/www/nextcloud is now owned by nobody:nogroup and I have never touch to him. Root is not capable to chown this directory.
Click to expand...
nobody (and nogroup) are shown when use numeric ID does not exist inside the container. Root inside the container is not actually root (on the host) and therefore is limited in its abilities (which is the whole reason for unprivileged containers). You need to chown with root from/on the host (and use the host user/group ID).
 
Making me crazy ! With UID/GID 33 on both side, data are well shared between host and container, but another directory I never touched is affected :

On container :
Code: 
root@nextcloud:/var/data_nextcloud# ls -la
total 28
drwxr-xr-x  5 www-data www-data 4096 Sep  2 20:03 .
drwxr-xr-x 13 root     root     4096 Sep  2 20:01 ..
-rw-r--r--  1 www-data www-data  542 Sep  2 19:40 .htaccess
-rw-r--r--  1 www-data www-data    0 Sep  2 19:40 .ocdata
[...]
-rw-r-----  1 www-data www-data    1 Sep  2 19:45 nextcloud.log
root@nextcloud:/var/data_nextcloud# cd ..
root@nextcloud:/var# cd www/
root@nextcloud:/var/www# ls -la
total 16
drwxr-xr-x  4 root   root    4096 Aug 31 20:21 .
drwxr-xr-x 13 root   root    4096 Sep  2 20:01 ..
drwxr-xr-x  2 root   root    4096 Aug 31 20:07 html
drwxr-xr-x 15 nobody nogroup 4096 Aug 31 20:50 nextcloud

On host :
arch: amd64 cores: 1 features: nesting=1 hostname: nextcloud memory: 1024 mp0: /data/data_nextcloud/,mp=/var/data_nextcloud nameserver: 192.168.1.254 net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.254,hwaddr=B2:A7:1E:5D:B7:28,ip=192.168.1.237/24,type=veth onboot: 1 ostype: debian rootfs: local-lvm:vm-101-disk-0,size=8G swap: 512 unprivileged: 1 lxc.idmap: u 0 100000 33 lxc.idmap: g 0 100000 33 lxc.idmap: u 33 33 1 lxc.idmap: g 33 33 1 lxc.idmap: u 34 100034 65502 lxc.idmap: g 34 100034 65502
 
leesteken said:
nobody (and nogroup) are shown when use numeric ID does not exist inside the container. Root inside the container is not actually root (on the host) and therefore is limited in its abilities (which is the whole reason for unprivileged containers). You need to chown with root from/on the host (and use the host user/group ID).
Click to expand...
Well, so, where am I supposed to do that chown ? And with id 100000 in the host ?
 
When changing remapping from 33 to 100033 to 33 to 33 your LXC looses all access to stuff previously owned by UID 33 inside the LXC. Before the change all files owned by UID 33 inside the LXC where actually owned by UID 100033 on the host. After changing the remapping UID 33 inside the LXC, the UID 33 inside the LXC can only access stuff that is owned by UID 33 on the host. But changing userremapping won't change any rights on folders. All stuff previously owned by UID 100033 is still owned by 100033 but your UID 33 inside the LXC isn't mapped to UID 100033 anymore, so all stuff owned by UID 100033 is now unaccessible. You would need to change the owner of everything owned by UID 100033 to UID 33. And this can only be done on the host as your LXCs root user got no root rights because its still a normal unprivileged user with UID 100000.
 
Last edited:
Dunuin said:
When changing remapping from 33 to 100033 to 33 to 33 your LXC looses all access to stuff previously owned by UID 33 inside the LXC. Before the change all files owned by UID 33 inside the LXC where actually owned by UID 100033 on the host. After changing the remapping UID 33 inside the LXC, the UID 33 inside the LXC can only access stuff that is owned by UID 33 on the host. But changing userremapping won't change any rights on folders. All stuff previously owned by UID 100033 is still owned by 100033 but your UID 33 inside the LXC isn't mapped to UID 100033 anymore, so all stuff owned by UID 100033 is now unaccessible. You would need to change the owner of everything owned by UID 100033 to UID 33 on the host.
Click to expand...
Thanks for your answer. The reason you say is pretty clear. The fact is that all the other datas owned by www-data on the container are not on the share. They are on the disk of the container.

I found that the container's disk was here :
Code: 
root@proxmox:/dev/pve# ls -la
total 0
drwxr-xr-x  2 root root  140 Sep  2 21:23 .
drwxr-xr-x 20 root root 4460 Sep  2 21:23 ..
lrwxrwxrwx  1 root root    7 Sep  2 21:23 root -> ../dm-1
lrwxrwxrwx  1 root root    7 Sep  2 21:23 swap -> ../dm-0
lrwxrwxrwx  1 root root    7 Sep  2 21:23 vm-100-disk-0 -> ../dm-6
lrwxrwxrwx  1 root root    7 Sep  2 21:23 vm-101-disk-0 -> ../dm-7

With the config file :
Code: 
# cat 101.conf
arch: amd64
cores: 1
features: nesting=1
hostname: nextcloud
memory: 1024
mp0: /data/data_nextcloud/,mp=/var/data_nextcloud
nameserver: 192.168.1.254
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.254,hwaddr=B2:A7:1E:5D:B7:28,ip=192.168.1.237/24,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-101-disk-0,size=8G

But with that informatin, I am not able to access the datas and change the ownership...
 
Last edited:
Do you think that my sharing is very special ? I am surprised to have that kind of problem. Do you have a better idea to share the data owned by www-data in the container with the host ? And I would like to use the storage of the host directly for backup purpose (I have a 500GB disk for the Proxmox OS and the containers and a 2TB for data I want to share through some containers (music, pictures, nextcloud data...).
 
gannick said:
Thanks for your answer. The reason you say is pretty clear. The fact is that all the other datas owned by www-data on the container are not on the share. They are on the disk of the container.

I found that the container's disk was here :
Code: 
root@proxmox:/dev/pve# ls -la
total 0
drwxr-xr-x  2 root root  140 Sep  2 21:23 .
drwxr-xr-x 20 root root 4460 Sep  2 21:23 ..
lrwxrwxrwx  1 root root    7 Sep  2 21:23 root -> ../dm-1
lrwxrwxrwx  1 root root    7 Sep  2 21:23 swap -> ../dm-0
lrwxrwxrwx  1 root root    7 Sep  2 21:23 vm-100-disk-0 -> ../dm-6
lrwxrwxrwx  1 root root    7 Sep  2 21:23 vm-101-disk-0 -> ../dm-7

With the config file :
Code: 
# cat 101.conf
arch: amd64
cores: 1
features: nesting=1
hostname: nextcloud
memory: 1024
mp0: /data/data_nextcloud/,mp=/var/data_nextcloud
nameserver: 192.168.1.254
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.254,hwaddr=B2:A7:1E:5D:B7:28,ip=192.168.1.237/24,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-101-disk-0,size=8G

But with that informatin, I am not able to access the datas and change the ownership...
Click to expand...
I really mean EVERYTHING owned by UID 100033 that LXC got access to. You changed the mapping for the whole LXC, not just for the bind-mount. So also all stuff on your LXCs root filesystem previously owned by UID 33 isn't accessible anymore because its in reality owned by UID 100033 and UID 33 in the LXC isn't UID 100033 anymore.

So you have to mount the LXCs virtual disks on the PVE host and chown everything from UID 100033 to 33.
 
Last edited:
Dunuin said:
I really mean EVERYTHING owned by UID 100033 that LXC got access to. You changed the mapping for the whole LXC, not just for the bind-mount. So also all stuff on your LXCs root filesystem previously owned by UID 33 isn't accessible anymore because its in reality owned by UID 100033 and UID 33 in the LXC isn't UID 100033 anymore.

So you have to mount the LXCs virtual disks on the PVE host and chown everything from UID 100033 to 33.
Click to expand...
Thanks. That works. What I did :
mount /dev/pve/vm-101-disk-0 /mnt find /mnt -user 100033 -exec chown 33:33 {} \;

So, thank you @Dunuin and @leesteken.

Last question because I am frustrated. Why does it is working with 33:33 mapped on both side, but not with 1000:1000 on host mapped with 33:33 on container ? Sorry, but I like to understand... :)
 
You must log in or register to reply here.
Top Bottom