That’s expected as the LXD snap doesn’t know about /etc/subuid and /etc/subgid, instead running with a much larger range that’s typically enough for any uses and without restrictions as to what uid/gid it can use if needed.
Is there a particular reason that you need your containers on the 165536 -> 165536+65536 range?
Hmm, yeah, that might get you past the 1000000000 uids/gids you get in your container. You’d have the same problem with the original map though.
Your best bet is to tweak your samba config to use a lower base uid or a different way of assigning them. I’m using sssd here for samba4 authentication and those uids usually start around 200000 instead.
Thanks for the info. I’ve turned ldap_id_mapping to false in /etc/sssd.conf and my userid is now 10006. We’ll see if this fixes the problem.
And FYI, there is a ton of information on the web that directs one to modify the /etc/subuid and /etc/subgid files as one means of dealing with user/group mapping. Information that is evidently incorrect regards LXD installed as a snap.
Yeah, subuid/subgid has been enough of a pain for people to figure out that we’ve decided to not care about it with the snap. The mechanism was designed to enforce slices of uids/gids on a per-user basis, assuming that every user on a system would get their own allocation.
This was and still is used by some users of completely unprivileged LXC, but those are a very small minority. Everyone else runs container managers as root where it makes little sense to go through subuid/subgid when you can access any uid/gid directly anyways.
In LXD 3.8 snap version the values for security.idmap.base and security.idmap.size are only considered with if you also set security.idmap.isolated=true! The result is as expected. Thanks for reading.