Just wondering if someone has an opinion about this phenomena I ran into. I set up profiles and created running instances on my Ubuntu incus host running incus 6.0.5 from zabbly. For vraious reasons I am running the containers with raw.idmap: | gid 5 5.
I moved the same setup - profiles and instances - to incus 6.8 on a RockyLinux host (from copr:copr.fedorainfracloud.org:neil:incus). On Rocky, the containers fail to start because I didn’t have a GID mapping in /etc/subgid… But I don’t have that on Ubuntu either and it doesn’t complain.
I also noted that newgidmap isn’t available (as far as I can see) on Ubuntu so that may point to some difference in the way the OS behaves…
But I’m stumped to explain why it even works on Ubuntu without the mapping in subgid. Does that make any sense?
It simply depends on whether your distro has the uidmap package installed or not.
Thanks, that makes sense. Sometimes these things are surprisingly simple.
Although I did get an error on Ubuntu (where uidmap is not installed) when I tried to start a container with a idmap base set to a value that wasn’t covered in the range set in subuid.
So maybe the behavior without uidmap is less restricted but still it matters?
LXC itself shouldn’t care when uidmap isn’t installed, but Incus will have picked up a fallback map, I believe it’s a very large chunk of uid/gid starting at uid/gid 1000000 so there can still be situations where you end up outside of that range.
Yup - makes total sense. I can run incus containers without the subuid entries on a host that does not have uidmap installed. It does indeed default to 1000000 as the default base for the UID mapping. Now it makes sense!
I think that for the sake of keeping control over things, it would be advisable to have uidmap installed with incus.