On Fri, Jan 21, 2022 at 03:59:52PM +0000, gmgod@xxxxx wrote: > Dear all, > > Has anyone tried to run a rootless container, or simply pull an image, from a systemd-homed session? > > For some reason I am told there are potentially insufficient UIDs or GIDs available: > > $ buildah from quay.io/fedora/fedora > Trying to pull quay.io/fedora/fedora:latest... > Getting image source signatures > Copying blob 4545346f2a49 done > writing blob: adding layer with blob "sha256:4545346f2a492b62d5a82682efe19b0e8e7583d5c19f75a74c81d62ec536c32d": Error processing tar file(exit status 1): potentially insufficient UIDs or GIDs available in user namespace (requested 0:12 for /var/spool/mail): Check /etc/subuid and /etc/subgid: lchown /var/spool/mail: invalid argument > > But my /etc/sub{u,g}id are properly populated, `podman system migrate` runs without complaining and the subids *are* just available: > > $ buildah unshare cat /proc/self/uid_map > 0 60097 1 > 1 100000 65536 > > This is only happening in systemd-homed user sessions: normal users just work. > Using `sudo homectl with <user> -- buildah from quay.io/fedora/fedora` also works. > > It looks like an important capability is dropped in systemd-homed session specifically that prevents id change. > Do you have any idea what it could be? Hey Gaël, I've spent some time looking into this as I had a hunch where the issue comes from. This is related to how systemd implements home directories making use of idmappings for the user's home directory on kernels that support it. As it stands systemd-homed allocates a very narrow range of ids for a users home directory causing podman and other tools to not be able to write ids in ranges > 60513. As you can see podman - with your mapping - tries to write as uid 100000 but that id isn't mapped in systemd-homed. I'll try to come up with a patch that fixes this and will propose it for systemd upstream. Thanks! Christian