Your container appears to run as a user (rootless) container, built on user namespaces.
In order to work, user containers have an associated uid/gid mapping to convert host uid/gid to container uid/gid. The overall host range for these is 2^32 wide (starting with 0 being real root user). From this, the allocated range to the container is usually kept at 2^16 (which is compatible with historical uid ranges).
Any host uid which has no range translation to an uid inside the container will appear as nobody (resp: nogroup for gid) inside the user container. As this container's root has no rights over such an uid, it can't alter it and the operation fails as when run by a normal user.
Here's a link from Proxmox describing your problem:
However you will soon realise that every file and directory will be
mapped to "nobody" (uid 65534), which is fine as long as
- you do not have restricted permissions set (only group / user readable files, or accessed directories), and
- you do not want to write files using a specific uid/gid, since all files will be created using the high-mapped (100000+) uids.
There are tools dedicated to translate those ranges, so a prepared system tree layout can be shifted into a range suitable for the target container. Those tool must be run from the host (or at least in case of "recursive" containers, the container having "spawned" the user namespace). For example:
which is a reimplementation of apparently defunct project nsexec's uidmapshift:
You can of course do this manually by calculating the right target uid:gid and using
chown (from host). If there's one value and a simple mapping it should be easy. Here's an example (using a running user LXC container):
Container (called buster-amd64):
user@buster-amd64:~$ ls -n test
-rw-r--r--. 1 65534 65534 0 Jan 24 21:09 test
root@buster-amd64:/home/user# chown user:user test
chown: changing ownership of 'test': Operation not permitted
Host (displaying same file):
user@host:~$ ls -n ~/.local/share/lxc/buster-amd64/rootfs/home/user/test
-rw-r--r--. 1 1000 1000 0 Jan 24 22:09 /home/user/.local/share/lxc/buster-amd64/rootfs/home/user/test
The command below gets the init process' pid (which is 1 in the container, but here the pid value as seen on host) running in the container (any other process of the container would work as well):
user@host:~$ lxc-info -Hpn buster-amd64
user@host:~$ cat /proc/22926/uid_map
0 1410720 65536
This mapping should have been defined in the LXC configuration:
user@host:~$ grep lxc.idmap ~/.local/share/lxc/buster-amd64/config
lxc.idmap = u 0 1410720 65536
lxc.idmap = g 0 1410720 65536
If the user container's uid is 1000 and the file/directory should belong to this user, then the new host's uid should be 1410720 + 1000 = 1411720
On the host, this time as (real) root user:
root@host:~# chown 1411720:1411720 ~user/.local/share/lxc/buster-amd64/rootfs/home/user/test
In case the container's filesystem(s) is not directly mounted somewhere on an host's filesystem (eg: using LVM backing store or tmpfs mount) and thus not reachable, this works too with a running container (and should probably be preferred anyway):
root@host:~# chown 1411720:1411720 /proc/22926/root/home/user/test
And now on the container:
user@buster-amd64:~$ ls -n test
-rw-r--r--. 1 1000 1000 0 Jan 24 21:09 test
And its root user now has rights over this file, because it's in the correct uid/gid mapping.
root@buster-amd64:~# chown root:root ~user/test
There is work in progress on the kernel side with a feature called shiftfs which is still changing form to help alleviate these problems by doing this translation over a bind mount.