lxc.idmap - home directory nobody nogroup

[Dark:Helmet]

Howdy...

I just added a disk to proxmox host, making it available to a container through the following configuration (precisely through the 6 lxc.idmap lines):

arch: amd64
cores: 2
features: nesting=1
hostname: nxt
memory: 8192
mp0: /media/hdd,mp=/media/nasdisk
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=64:ED:BA:AE:79:DA,ip=dhcp,ip6=auto,ta>
ostype: debian
rootfs: local-lvm:vm-108-disk-0,size=24G
swap: 8192
unprivileged: 1
lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1001 1
lxc.idmap: g 1000 1001 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535

Please note that user "nxt" comes on the host with UID/GID 1001 as for the container with UID/GID 1000.

This works quite well as I am now able to write on that disk as expected.

/media/nasdisk$ ls -n
drwxrwxr-x 8    0 1002  4096 Dec  6 22:44 NAS
drwxr-xr-x 3    0    0  4096 Jun 30  2019 NC
drwxr-xr-x 2 1000 1000  4096 Jan 21 16:47 images
drwx------ 2 1000 1000 16384 Jan 16 20:47 lost+found
drwxr-xr-x 4    0    0  4096 Nov 17  2019 temp

/media/nasdisk$ ls -lha
drwxrwxr-x 7 root messagebus 4.0K Nov 17  2019 .
drwxr-xr-x 4 root root       4.0K Jan 22 14:57 ..
drwxrwxr-x 8 root nasshare   4.0K Dec  6 22:44 NAS
drwxr-xr-x 3 root root       4.0K Jun 30  2019 NC
drwxr-xr-x 2 nxt  nxt        4.0K Jan 21 16:47 images
drwx------ 2 nxt  nxt         16K Jan 16 20:47 lost+found
drwxr-xr-x 4 root root       4.0K Nov 17  2019 temp

The only flaw is that the home directory inside the container appears now to be read only. Taking a closer look brings up nobody:nogroup on user's home directory:

/home$ ls -n
drwxr-xr-x 6 65534 65534 4096 Jan 24 12:31 nxt

/home$ ls -lha
drwxr-xr-x  6 nobody nogroup 4.0K Jan 24 12:31 nxt

Now how do I accomplish that home directory in CT of user nxt (1000:1000 inside the container) will be (write) available to user nxt again?

Thanks in advance - your help is appreciated!

Cheers
Dark Helmet

 

[Dark:Helmet]

Now that appears to be a mapping issue. Just played around with the lxc config file..:

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

...plus..:

# /etc/subuid
root:1000:1

...plus..:

# /etc/subgid
root:1000:1

...did the trick (although this doesn't feel right).

 

[amccallum]

I'm having the exact same issue, however the provided fix causes the bind mount to be nobody:nobody instead.

Host:

arch: amd64
cores: 1
features: nesting=1
hostname: qbittorrent
memory: 512
mp0: /mnt/bindmounts/media/downloads,mp=/media/downloads
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=DA:8C:E5:BA:0A:F8,ip=dhcp,type=veth
ostype: debian
rootfs: probox:vm-103-disk-0,size=201G
swap: 512
unprivileged: 1
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

Guest:

qbtuser:x:1000:1000:,,,:/home/qbtuser:/bin/bash

ls /media -l
total 4
drwxr-xr-x 2 qbtuser qbtuser 4096 Jun  5 22:19 downloads

ls /home -l
total 4
drwxr-xr-x 6 nobody nogroup 4096 Mar 30 04:18 qbtuser

I will try the fix provided here in the meantime.

 

[fabian]

well, you can only have one mapping per user - if the user was already mapped using the default mapping before you added your custom mapping, and files/dirs exist with ownership based on that old mapping, you need to manually fix them up. easiest way is to use "pct mount" and then fix the ownership using chown (both outside of the container, directly on the hypervisor..)