11:48 a.m.
On Mon, Feb 21, 2022 at 4:44 AM Prafulla Giri
<prafulla.giri(a)protonmail.com> wrote:
Hmm... I think I'm starting to get it now.
I just ran
`$ podman run --rm --uidmap 1000:0:1 --uidmap 0:1:1000 -v ./gogsfoo:/data
docker.io/gogs/gogs` and on exit ./gogsfoo is owned by my regular user.
I suppose the final `--uidmap 1001:1001:$(($subuidsize-1000))` where $subuidsize is `cat
/etc/subuid | cat -d: -f 3` is just a precaution, and my aforementioned command would have
failed if there were a user 1001 inside the container, because then podman would be like
"I don't know where to map it", I presume?
Yes, Podman would have problems creating the container if it contains
files or directories owned by the user. For instance this
Containerfile:
FROM docker.io/gogs/gogs
RUN useradd -u 1001 -m extrauser
leads to this error message
$ podman run --rm --uidmap 1000:0:1 --uidmap 0:1:1000 localhost/extra
Error: error creating container storage: error creating an ID-mapped
copy of layer
"12e80c7e88c3f1123da63a0e550344f5360ac54b69543a78a54d7436df781da5":
exit status 1: error during chown: error mapping container ID pair
idtools.IDPair{UID:1001, GID:1001} for "home/extrauser" to host:
Container ID 1001 cannot be mapped to a host ID
I wonder... if we had something whereby, on exit, podman reverted the ownership of all
files in the subuid range (as specified by /etc/subuid) back to the user, automatically
(or if there a flag to make it do so), it would be of tremendous help to the users.
An alternative could also be to run
podman unshare chown -R $(id -u):$(id -g) volumedir/
afterwards.