Unable to map to 'www-data' user in container

Yanwoo

Member
Oct 27, 2017
21
0
6
64
For the last year or so I've had a container running that has map of an 'nc' user (uid: 1005) on my pve host to 'www-data' (uid: 33) in an LXC unprivileged container. Has worked flawlessly.

However, recently I had cause to restore from a backup and I was getting a bunch of errors related to permissions in the recovered container. At first I thought it was an issue with the backup/recovery process, but in attempting to rebuild from a fresh container I ended up running into exactly the same issue with permissions not working as expected.

It appears that I am now unable to map to the 'www-data' user in a container. Whenever I try to do that, all folders and files owned by that group switch to ownership by 'nobody:nogroup'. I can map to other users just fine, it just seems to be this one specific user.

Is there something special about the 'www-data' user that is causing this issue? And is a little baffling why it's worked for a year (and container has been started and stopped many times) and now seems to have stopped working. I've recently updated to the latest pve, so wondering if something has changed?

pve version: pve-manager/5.3-5/97ae681d (running kernel: 4.15.18-9-pve)

container config file
Code:
mp0: /mnt/pve/remote-stagnum-nc-yanwoo,mp=/mnt/yanwoo
mp1: /mnt/pve/remote-stagnum-nc-nina,mp=/mnt/nina
arch: amd64
cores: 1
hostname: nextcloud
memory: 1024
net0: name=eth0,bridge=vmbr0,hwaddr=1a:58:64:75:1e:48,ip=dhcp,tag=60,type=veth
onboot: 1
ostype: ubuntu
rootfs: local-zfs-storage:subvol-220-disk-0,size=30G
startup: order=4
swap: 0
unprivileged: 1
lxc.idmap: u 0 100000 33
lxc.idmap: g 0 100000 33
lxc.idmap: u 33 1005 1
lxc.idmap: g 33 1005 1
lxc.idmap: u 34 100034 65501
lxc.idmap: g 34 100034 65501

/etc/subuid
Code:
root:100000:65536
root:1005:1
root:33:1

/etc/subuid
Code:
root:100000:65536
root:1005:1
root:33:1


In summary: when I map to the 'www-data' user in a container, ownership of all www-data folders and files in the container changes to nobody:nogroup. Setup has previously been working for a while but has recently stopped working (maybe from a pve update?) ... and can map successfully to other users in the container without issue.
 
Hello!

Can you try the following commands as root?

Code:
pct mount CTID
find /var/lib/lxc/CTID/rootfs -uid 100033 -exec chown 1005 '{}' \;
find /var/lib/lxc/CTID/rootfs -gid 100033 -exec chgrp 1005 '{}' \;

It seems like an issue about ignoring the custom mapping during restore operation. It will be looked into soon, you can follow the bug on https://bugzilla.proxmox.com/show_bug.cgi?id=2028
 
Great, thanks oguz!

Yes, that works and has corrected the mapping and fixed the issue.
 
I run into the exact same issue, with the same user-id combo.

I checked every number twice, but I could not find the issue with my mapping. Then I removed the lxc.idmap completely from the CT conf, including entries in /etc/subuid and /etc/subgid - surprise: It did not make any difference, the container would still complain on startup - even though no idmap was defined anymore in the conf.

The workaround described above helped.

Just curious: This was 2018. I am running:

Code:
pve-manager/6.3-3/eee5f901 (running kernel: 5.4.78-2-pve)

Hasn't this been merged already?

Finally, one last question regarding entries in /etc/subuid and /etc/subgid:
Yanwoo suggested to add root:33:1 - Why? To me, this entry means: allow CT to use the user with id 33 on the host. But 33 is www-data in the CT - no need to allow the CT access to www-data on the host, correct?
Anyway, not adding root:33:1 works for me.

For completeness, these are the (working) conf entries:

/etc/pve/lxc/100.conf
Code:
lxc.idmap: u 0 100000 33
lxc.idmap: g 0 100000 33
lxc.idmap: u 33 1005 1
lxc.idmap: g 33 1005 1
lxc.idmap: u 34 100034 65502
lxc.idmap: g 34 100034 65502

/etc/subuid
Code:
root:100000:65536
root:1005:1

/etc/subgid
Code:
root:100000:65536
root:1005:1
 
Last edited:
/etc/pve/lxc/100.conf
Code:
lxc.idmap: u 0 100000 33
lxc.idmap: g 0 100000 33
lxc.idmap: u 33 1005 1
lxc.idmap: g 33 1005 1
lxc.idmap: u 34 100034 65502
lxc.idmap: g 34 100034 65502
As far as I know that should map...
GID 0-32 to 100000-100032
GID 33 to 1005
GID 34-65535 to 100034-165535
UID 34-65535 to 100034-165535
UID 33 to 1005

UID 0-32 are not mapped
 
As far as I know that should map...
GID 0-32 to 100000-100032
GID 33 to 1005
GID 34-65535 to 100034-165535
UID 34-65535 to 100034-165535
UID 33 to 1005

UID 0-32 are not mapped
Yes, this was what I needed: Only map GID 33 to 1005 and UID 33 to 1005 - I wasn't able to leave out the other mappings since proxmox would complain that the mapping is invalid on startup.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!