How can I change the ownership of a directory with nobody:nogroup? Everything I tried ended up with "operation not permitted".

cat /etc/debian_version

root@torrent:/srv# chown -R rtorrent:rtorrent rtorrent 
chown: cannot read directory 'rtorrent/.local/share': Permission denied
chown: changing ownership of 'rtorrent/.local': Operation not permitted
chown: changing ownership of 'rtorrent/.bash_history': Operation not permitted
chown: changing ownership of 'rtorrent/session/rtorrent.dht_cache': Operation not permitted
chown: changing ownership of 'rtorrent/session': Operation not permitted
chown: changing ownership of 'rtorrent/.rtorrent.rc': Operation not permitted
chown: changing ownership of 'rtorrent/download': Operation not permitted
chown: changing ownership of 'rtorrent/watch': Operation not permitted
chown: changing ownership of 'rtorrent': Operation not permitted

rm -r download/
rm: cannot remove 'download/': Permission denied
root@torrent:/srv/rtorrent# ls -al
total 32
drwxr-xr-x 6 nobody nogroup 4096 Jan 24 18:16 .
drwxr-xr-x 3 root   root    4096 Jan 24 16:46 ..
-rw------- 1 nobody nogroup   47 Jan 24 18:16 .bash_history
drwxr-xr-x 3 nobody nogroup 4096 Jan 24 18:15 .local
-rw-r--r-- 1 nobody nogroup 3224 Jan 24 18:16 .rtorrent.rc
drwxr-xr-x 2 nobody nogroup 4096 Jan 24 16:46 download
drwxr-xr-x 2 nobody nogroup 4096 Jan 24 18:21 session
drwxr-xr-x 2 nobody nogroup 4096 Jan 24 16:46 watch
  • Is rtorrent a mount point? – Stephen Kitt Jan 24 at 19:12
  • No, it is the home directory of rtorrent user. I changed the primary group of this user and ended up here. – toma3757 Jan 24 at 19:14
  • The output of lsof | grep rtorrent and mount would be helpful. – gabor.zed Jan 24 at 20:10
  • Is the /srv/rtorrent directory set immutable with chattr +i? Use the lsattr -d /srv/rtorrent command to check. Debian 10 has AppArmor but it should not restrict root, unless you are logging in in some strange way. – telcoM Jan 24 at 20:37
  • @gabor.zed The output of lsof is empty, mount also. The rtorrent service not running. – toma3757 Jan 24 at 20:37

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.

|improve this answer|||||
  • Thank you for the answer. I'm totally new in these things. There is one thing what I don't understand. In the container I created these files/dirs, with 107:115 owner:group and everything was fine, the owner user had acces to these but after a reboot it changed to nobody:nogroup. Why is this changed? How can I avoid it in the future? – toma3757 Jan 24 at 22:38
  • 1
    I don't have enough informations for this. This could be a process run from the host writing with wrong ownership, one could imagine you're using overlayfs/aufs and there's a bug causing a wrong ownership on remount, or many other reasons. I can just tell you that you can correct the ownership, but only from the host, probably only as root. If the problem reappears on each reboot (of container only? of host?) there is more investigation to do, and that deserves an other question here. – A.B Jan 24 at 22:43
  • Thanks! I will post a new one, beacuse this case happened in my other container too. I think I messed up something very well. – toma3757 Jan 24 at 22:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.