Your message dated Fri, 8 Dec 2023 19:29:45 +0200
with message-id <zxnsiysjokery...@tty.gr>
and subject line Re: Bug#1042090: podman: fails to start container with userns
mapping
has caused the Debian Bug report #1042090,
regarding podman: fails to start container with userns mapping
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1042090: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042090
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: podman
Version: 4.3.1+ds1-8+b1
Severity: normal
X-Debbugs-Cc: hri...@venev.name
Dear Maintainer,
When trying to run a container using podman (as root) with a uid/gid
mapping specified via `--userns`, it fails to start:
> # podman run --rm --userns auto:uidmapping=1000:1001:1,gidmapping=1000:1001:1
> debian:12
> ERRO[0000] Unmounting
> /var/lib/containers/storage/overlay/INSERT_ID_HERE/merged: invalid argument
> Error: mounting storage for container INSERT_ANOTHER_ID_HERE: creating
> overlay mount to /var/lib/containers/storage/overlay/INSERT_ID_HERE/merged,
> mount_data="lowerdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_SHORT_ID_HERE:/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/diff1:/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_ANOTHER_SHORT_ID_HERE,upperdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/diff,workdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/work,,volatile":
> permission denied
The following appears in the kernel log:
> [TIME] overlayfs: failed to resolve
> '/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_SHORT_ID_HERE':
> -13
The outcome is listed above. The expected outcome was that the container
would start, with most IDs mapped from those delegated to the
`containers` user, except uid/gid 1000 inside the container which
correspond to 1001 outside.
Running the container with just `--userns auto` works. However, then all
files passed to the container via bind mounts would be owned by
nobody:nogroup instead of 1000:1000.
This seems similar to https://github.com/containers/podman/issues/18435,
which was probably fixed in podman 4.5.0.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-1-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages podman depends on:
ii conmon 2.1.6+ds1-1
ii crun 1.8.5-1
ii golang-github-containers-common 0.50.1+ds1-4
ii libc6 2.37-6
ii libdevmapper1.02.1 2:1.02.185-2
ii libgpgme11 1.18.0-3+b1
ii libseccomp2 2.5.4-1+b3
ii libsubid4 1:4.13+dfsg1-1+b1
Versions of packages podman recommends:
pn buildah <none>
pn catatonit | tini | dumb-init <none>
pn dbus-user-session <none>
pn fuse-overlayfs <none>
pn slirp4netns <none>
pn uidmap <none>
Versions of packages podman suggests:
pn containers-storage <none>
pn docker-compose <none>
ii iptables 1.8.9-2
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 4.6.2+ds1-2
On Mon, Oct 30, 2023 at 10:12:19AM +0000, Sebastian Sams wrote:
> I’ve just stumbled across this bug when upgrading to bookworm, had the
> same issue with a container using the „userns“ on version 4.3.1+ds1-8.
>
> For me simply upgrading to the package from testing (-> currently
> 4.6.2+ds1-2) as suggested worked and solved the issue, no further
> actions required.
Thanks for the confirmation!
> Is it planned to backport the fix to bookworm?
That's unlikely... If you look at the upstream issue (#18435), it's not
clear which commit(s) fixed this. The recommendation there was to
"please try with the latest podman release, there were many fixed for
the idmapped mounts feature."
But if you are able to figure out the responsible commits, I can have a
look at backporting them.
The other option of course is to provide a newer podman version through
bookworm-backports. But that's also complicated due to the big
dependency chain, so I'm not personally planning to spend any time on
it... (Not sure about Reinhard or anyone else)
Regards,
Faidon
--- End Message ---
_______________________________________________
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
