I’ve ran into some strange problem - I’m getting nobody:nogroup (65534:65534) ownership on bind-mount’ed files and file-like objects (e.g. /proc, /sys, /dev/urandom, …) inside my unprivileged containers. All of them have “lxc.idmap = u 0 100000 65536” and “lxc.idmap = g 0 100000 65536” configured. The host system has correct subuid and subgid ranges for the user containers are running under. I’ve tried Debian Buster created from template and manually assembled NixOS distro - both have this problem preventing them from functioning normally.
On the other hand, privileged containers with the same distros work as expected and there are no unexpected files with nobody:nogroup ownership.
I’ve only recently switched to lxc/lxcfs 3.0 and I don’t remember having this problem on 2.1. My current host is Arch with 4.16.5 kernel.
What could be the reason for such strange ownership? Any help would be greatly appreciated! Thanks in advance!
BTW: I’m not sure that the problem is entirely on lxc side so I’ve asked a related question on nixos mailing list.
65534 is used by the kernel to represent a uid/gid which is outside of the container’s map.
This can only be observed inside unprivileged containers as they are the only ones with such a map in place.
It’s normal for the kernel filesystems (/sys, /proc, …) to show up as such as those paths are owned by real root and not by the container root. The same goes for anything that you pass from outside the container. Unless the owner outside the container matches a uid/gid in the map of the container, they will similarly show up as 65534.
What’s the actual problem? Having the ownership of /proc and /sys be 65534 isn’t by itself a problem, so I’m guessing you have issues accessing a particular file.
Sorry for disappering and thanks for the explanation! In fact, my original problem was kind of solved here. I believe that now it’s NixOS’ problem =)
However it’s not entiryly clear for me why there is no mapping done between host and container root uid/gid. Some fundamental problem? Lack of manpower? Or just not necessary? Maybe you could suggest some links to read on this topic?
procfs and sysfs are very special virtual filesystems in the kernel which don’t really know much about owernship/modes as other filesystems do.
@tyhicks on our team is looking at fixing some of the actual permission problems with sysfs, but reported ownership/modes is purely cosmetic at this point and so not really a priority to fix.