root not able to chmod all folder after chaning user-remapping of unprivileged LXC

Dunuin

Distinguished Member
Jun 30, 2020
14,311
4,198
243
Germany
Hi,

I wanted to install UrBackup inside a unprivileged LXC and this UrBackup LXC should store the backups on a NFS share on my TrueNAS server.

On my TrueNAS server I created a dataset mounted at /mnt/HDDpool/UrBackup", created a user/group "urbackup" (UID/GID 1130) and set this user/group with 770 rights as the owner of that dataset. Then I created a NFS share for that dataset and set the "Maproot User" and "Maproot Group" to "urbackup" (so I guess users accessing that share only got the rights of my urbackup user, or did I misuderstand that?).

Because unpriviled LXCs can't mount shares I mounted that NFS share on my PVE host using fstab:
Code:
192.168.49.4:/mnt/HDDpool/UrBackup              /media/UrBackup/                nfs     defaults,nfsvers=3                                                                      0       0
I used "nfsvers=3" because somehow using NFS4 I don't get NFS working.
I also created user/group "urbackup" (UID/GID 1130) on my PVE host and created the folder "/media/UrBackup/" owned by root. If I run "mount -a" the NFS share gets mounted on the PVE host: drwxrwx--- 2 urbackup urbackup 2 Oct 27 00:05 UrBackup

Inside my LXC I then created a user/group "urbackup" (UID/GID 1130) and created a folder "/media/UrBackup" owned by root.

On the PVE host I then added this to the LXCs config file...
Code:
lxc.idmap: u 0 100000 1130
lxc.idmap: g 0 100000 1130
lxc.idmap: u 1130 1130 1
lxc.idmap: g 1130 1130 1
lxc.idmap: u 1131 101131 64405
lxc.idmap: g 1131 101131 64405
mp0: /media/UrBackup,mp=/media/UrBackup
...like I did it many times before for other unprivileged LXCs that needed access to SMB shares. So UID 1130 on the host should be mapped to UID 1130 inside the LXC so that this fits the UID 1130 of my NFS share.

But now I'm not sure if I done it right with the subuid and subgid because I don't completely understand that part why it is needed at all.
I've added root:1130:1 to my subuid and subgid which should mean that root is allowed to access stuff owned by UID 1130 inside the LXC?

My subuid now looks like this:
Code:
root:1100:4
root:1130:1
root:100000:65536
snapshot:165536:65536
podsync:231072:65536
ps3games:296608:65536
ebooks:362144:65536
ydl:427680:65536
urbackup:493216:65536
"root:1100:4" is there because other unprivileged LXCs are using UID 1100 to 1103 to access SMB shares. Is that ok or is it maybe not allowed to have multiple "root" or multiple lines?

My subgid looks like this:
Code:
root:1100:4
root:1130:1
root:100000:65536
snapshot:165536:65536
podsync:231072:65536
ps3games:296608:65536
ebooks:362144:65536
ydl:427680:65536
urbackup:493216:65536

And why is there also a "/etc/subuid-" and "/etc/subgid-" file? Do I also need to add the "root:1130:1" line there? These look like my "/etc/subuid" and "/etc/subuid" just without the new "root:1130:1" line.

Inside my LXC I can see the bind-mounted NFS share but my root user isn't allowed to access it:
Code:
root@UrBackup:/media# ls -la
total 28
drwxr-xr-x  3 root     root      3 Oct 27 04:04 .
drwxr-xr-x 21 root     root     21 Oct 27 06:06 ..
drwxrwx---  2 urbackup urbackup  2 Oct 27 00:05 UrBackup
root@UrBackup:/media# cd UrBackup/
-bash: cd: UrBackup/: Permission denied

Same problem with the home folder of my urbackup user which is owned by nobody:nogroup instead of urbackup:urbackup like the NFS share:
Code:
root@UrBackup:/home# ls -la
total 41
drwxr-xr-x  3 root   root     3 Oct 27 03:43 .
drwxr-xr-x 21 root   root    21 Oct 27 06:06 ..
drwxr-xr-x  2 nobody nogroup  5 Oct 27 03:43 urbackup
root@UrBackup:/home# chown -R urbackup:urbackup /home/urbackup
chown: changing ownership of '/home/urbackup/.bashrc': Operation not permitted
chown: changing ownership of '/home/urbackup/.profile': Operation not permitted
chown: changing ownership of '/home/urbackup/.bash_logout': Operation not permitted
chown: changing ownership of '/home/urbackup': Operation not permitted

If I switch to the urbackup user using root@UrBackup:/home# su - urbackup I can't change rights of its home folder too...
Code:
urbackup@UrBackup:/home$ chown -R urbackup:urbackup /home/urbackup
chown: changing ownership of '/home/urbackup/.bashrc': Operation not permitted
chown: changing ownership of '/home/urbackup/.profile': Operation not permitted
chown: changing ownership of '/home/urbackup/.bash_logout': Operation not permitted
chown: changing ownership of '/home/urbackup': Operation not permitted
...which makes sense if only the owner got write access and its owned by nobody. But I can access the NFS share and write to it:
Code:
urbackup@UrBackup:/home$ cd /media/UrBackup
urbackup@UrBackup:/media/UrBackup$ ls -la
total 14
drwxrwx--- 2 urbackup urbackup 2 Oct 27 00:05 .
drwxr-xr-x 3 root     root     3 Oct 27 04:04 ..
urbackup@UrBackup:/media/UrBackup$ touch test.txt
urbackup@UrBackup:/media/UrBackup$ ls -la
total 15
drwxrwx--- 2 urbackup urbackup 3 Oct 27  2021 .
drwxr-xr-x 3 root     root     3 Oct 27 04:04 ..
-rw-r--r-- 1 urbackup urbackup 0 Oct 27  2021 test.txt

So there are 3 questions...

1.) Is someone using TrueNAS and can give me a hint how to setup NFS shares so that NFS4 can be used?
2.) How can I change the owner of "/home/urbackup" if the LXCs root isn't allowed to do that?
3.) Can I do something that the LXCs root user is allowed to do everything inside that LXC? Its really annoying if the root user isn't allowed to access folders owned by urbackup. I wanted to install the UrBackup server under the urbackup user so that would cause problems if system processes run by root aren't allowed to for example shutdown the UrBackup server or unmount stuff that was started/mounted by my urbackup user?
 
Last edited:
2.) How can I change the owner of "/home/urbackup" if the LXCs root isn't allowed to do that?
Ok, so I changed the owner of "/home/urbackup" inside the LXC as root from the the host:
Code:
root@Hypervisor:/VMpool/VLT/VM/subvol-131-disk-0/home# ls -la
total 41
drwxr-xr-x  3 100000 100000  3 Oct 27 03:43 .
drwxr-xr-x 21 100000 100000 21 Oct 28 06:06 ..
drwxr-xr-x  2 101130 101130  5 Oct 27 03:43 urbackup
root@Hypervisor:/VMpool/VLT/VM/subvol-131-disk-0/home# chown -R 1130:1130 urbackup
root@Hypervisor:/VMpool/VLT/VM/subvol-131-disk-0/home# ls -la
total 41
drwxr-xr-x  3   100000   100000  3 Oct 27 03:43 .
drwxr-xr-x 21   100000   100000 21 Oct 28 06:06 ..
drwxr-xr-x  2 urbackup urbackup  5 Oct 27 03:43 urbackup
Now that home folder belongs to the right user and my LXCs root user got read/write access there.

But my LXCs root user is still not allowed to access the bind-mounted NFS share:
Code:
root@UrBackup:/home/urbackup# cd /media/UrBackup/
-bash: cd: /media/UrBackup/: Permission denied
root@UrBackup:/home/urbackup# cd /media/
root@UrBackup:/media# ls -la
total 28
drwxr-xr-x  3 root     root      3 Oct 27 04:04 .
drwxr-xr-x 21 root     root     21 Oct 28 06:06 ..
drwxrwx---  2 urbackup urbackup  3 Oct 27 17:15 UrBackup
What would be the right way to solve this except for doing a chmod -R 777 /media/UrBackup where I don't really like giving everyone rights to read/delete my important backups?

Would it work to add root to the urbackup groups? Like this?
LXC: add UID 0 to GID 1130
PVE Host: add UID 100000 to GID 1130
TrueNAS Host: add UID 100000 to GID 1130

Or isn't that working because mapped UIDs/GID are always changing when you LXCs are created (looks like that if I look at the subuid file "urbackup:493216:65536")?

And why is there also a "/etc/subuid-" and "/etc/subgid-" file? Do I also need to add the "root:1130:1" line there? These look like my "/etc/subuid" and "/etc/subuid" just without the new "root:1130:1" line.
Found it in the manual. Files ending with "-" are backups.
 
Last edited:

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!