[SOLVED] Yet another LXC ID mapping thread - mapping multiple host IDs to a single container ID?

[sshaikh]

The problem:

I have a CIFS folder mounted on the host. As such I have little control over the permissions and owners of folders within that. However, since this folder is exclusively used for container mountpoints, I use the

uid=101000,gid=101000

parameters during mount to give them an appropriate UID so that the LXC mapping works (101000 becomes 1000 which is the UID of the main user in the container).

However a specific container has a main user with a UID of 998 (I do not know why). Therefore it is unable to write to this mountpoint, as its UID is still 1000.

I tried the following mapping:

lxc.idmap: u 0 100000 998
lxc.idmap: g 0 100000 998
lxc.idmap: u 998 101000 1
lxc.idmap: g 998 101000 1
lxc.idmap: u 999 100999 1
lxc.idmap: g 999 100999 1
lxc.idmap: u 1000 100998 1
lxc.idmap: g 1000 100998 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535

Thinking that mappings only apply to mount points. It turns out they do not, and this made the user's home directory inaccessible. Given how mappings are said to be transparent to the container, I'm not sure I understand why (I guess local storage is "externally" mapped too), and so I'm left puzzled at how to solve this.

tldr: How can I allow UID 998 to access a particular mountpoint without wrecking it's access to existing local storage?

 

[sshaikh]

I took the easy-cum-hard way and updated the the UID from 998 to 1000 in the container. Some tips if someone else would like to do this (not a script and definitely not recommended!):

pct enter xxx # to enter a running container outside of ssh (in case the user has processes etc)
usermod -u 1000 user # to change UID of user
groupmod -g 1000 usergroup # to change GID of group.
pct mount xxx # to mount a container's storage into the PVE host
find mount_dir -group 100998 -exec chgrp -h 101000 {} \; # to update gids of files
find mount_dir -user 100998 -exec chown -h 101000 {} \; # to update uids of files (although I didn't have to do this)