User id mapping seems not working properly in kernel 5.19.1 on Fedora #1308
Labels
Comments
|
Looks like kernel overlay @giuseppe PTAL |
|
I get the same on archlinux after upgrading to 5.19.1 on archlinux: The warning about POSIX ACL support is new for me. On another system changing the |
giuseppe
added a commit
to giuseppe/storage
that referenced
this issue
Aug 16, 2022
do not clone the source directory in recursive mode (the equivalent of MS_BIND|MS_RECURSIVE) but use only a regular bind mount. If not recursive bind mount is used then the existing overlay mounts are not replicated. In this way a new idmapped mount won't need to map the overlay mount as well, causing the mount_settattr(2) syscall to fail with EINVAL since it is not possible to idmap an overlay mount yet. Closes: containers#1308 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
PR here: #1309 |
|
This issue should not be closed as no release has been made since. We currently have a downstream ticket about this for Arch Linux: https://bugs.archlinux.org/task/75605 Please cut a new release of containers/storage, include it in podman and also cut a new podman release! :) |
|
Once the issue is fixed in upstream we close the issue, and allow it to bubble down to the downstream. Otherwise we would end up with ton's of open issues, which were already fixed. Down stream issues should be tracked in their own bug tracking systems. |
|
Is there any update to this? Not to rush anybody, we had a PR in August, we're almost in November and kernel 5.19 is still unusable... |
|
What kernel are you having an issue with? I believe this should be fixed in latest kernels. |
|
I had this issue on an up to date Fedora 36 system, and downgrading to kernel 5.17 fixed it. |
|
@rhatdan @giuseppe |
|
Does it work with different kernels? |
|
Yes, it works with the latest 5.17 kernel on Fedora 36. |
|
It is fixed upstream. It is an issue in c/storage, not in the kernel |
|
@giuseppe which commit exactly? |
|
@lukasmrtvy what is the underlying file system you are using? Podman 4.3.1 on Fedora has the required fix |
|
@giuseppe xfs Have some troubles ( Podman 4.3.1, FCOS 36.20221030.3.0 ) with SELinux, is it related to this fix? ( Not every container is failing tho ) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Steps to reproduce the issue:
There seems to be a problem if using the newest kernel 5.19.1 with userid mapping. Running multiple containers that use the same image at the same time throws error. For example, running
sudo podman run -it --userns auto -d docker.io/library/ubuntutwice will throw the errorI'm using Fedora 36 with the kernel here: https://koji.fedoraproject.org/koji/buildinfo?buildID=2044709
I've updated podman to the newest version 4.2.0 in the Fedora's
updates-testingrepo and the problem is still thereDescribe the results you received:
Shown above.
Describe the results you expected:
The container should run in detached mode, with container id printed as output.
Additional information you deem important (e.g. issue happens only occasionally):
Content of
/etc/subuidand/etc/subgid:After downgrading kernel to 5.18, everything works.
Output of
podman version:Output of
podman info:(This is the output of
sudo podman info)Package info (e.g. output of
rpm -q podmanorapt list podman):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
I can reproduce the problem with a fresh install of Fedora Server Edition in Virt Manager
The text was updated successfully, but these errors were encountered: