Error: open executable: Operation not permitted: OCI permission denied #9377
Comments
openshift-ci-robot
added
the
kind/bug
|
Can you upgrade to 3.0 final and see if the issue still occurs? |
|
Sure! I've installed the build from: https://koji.fedoraproject.org/koji/buildinfo?buildID=1708795 Now I have: But the exact same error remains: |
|
Permission denied usually means Security. Since this fails in rootless --privileged, I will try rootfull. Blows up there as well. At this point it looks like something strange is going on. Does this image work within Docker? I think your entrypoint is screwed up. This does not look like a podman bug. |
Yes it does. I tried it with docker before trying it with podman, and it works without problem. That's part of why I expected it to work with podman. Also note that this image is quite popular (5M+ pulls) and is even the one recommended by the hugo development team for using hugo through docker, as shown here: https://gohugo.io/getting-started/installing/ Thanks for the workaround though, this greatly helps! |
|
If this works on Docker and |
|
Ok then it is something wrong with the way we are handling entrypoint. |
|
The image has this: Which might be confusing us, and not confusing Docker. |
We recieved an issue with an image that was built with entrypoint=[""] This blows up on Podman, but works on Docker. When we setup the OCI Runtime, we should drop any fields that are "" within the entrypoint. containers#9377 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We recieved an issue with an image that was built with entrypoint=[""] This blows up on Podman, but works on Docker. When we setup the OCI Runtime, we should drop any fields that are "" within the entrypoint. containers#9377 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We recieved an issue with an image that was built with entrypoint=[""] This blows up on Podman, but works on Docker. When we setup the OCI Runtime, we should drop any fields that are "" within the entrypoint. containers#9377 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We recieved an issue with an image that was built with entrypoint=[""] This blows up on Podman, but works on Docker. When we setup the OCI Runtime, we should drop entrypoint if it is == [""] containers#9377 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We recieved an issue with an image that was built with entrypoint=[""] This blows up on Podman, but works on Docker. When we setup the OCI Runtime, we should drop entrypoint if it is == [""] containers#9377 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
|
Had a similar issue. Turned out that the have fixed that. Unfortunately the error messages was not clear about it. |
|
I got it in 3.4.4. when using rootless user. But I have the specific suspect: conmon. It looks strange: |
|
That error message re: |
|
@mheon I really trying to help to make Podman usable for "Normal GNOME-based workstations users". Unfortunately, regardless how image and container has been created I get OCI permission denied. If log-level-debug option is provided the log always contains the similar sequence of lines: |
|
Possible hint: |
|
I believe that Also, I again suggest you open a fresh issue, this is unrelated to the bug we're posting in. |
|
This looks like SELinux causing the issue, if you are on F36/Rawhide, there was an issue with the container-selinux package which could cause this porblem. |
|
@mheon, As I mentioned above Crun and Runc work similarly. If the SELinux labeling is suspected, please, explain why I see different executable files attributes of CRun, RunC (root system_u:object_r:container_runtime_exec_t:s0) and Conmon (oot system_u:object_r:bin_t:s0) and different owners from root and rootless ( root / nobody ). Is it installation glitch? |
|
If SELinux is causing issues, please attach the AVCs. |
|
Absolutely nothing is shown in the running SEAlert UI. But inside Container's runtime I found: |
|
Run semodule -DB before the failure, and see if additional AVC messages show up. ausearch -m avc -ts recent |
|
Actually, I expect to see that container in the runtime references the "writable snapshot" of the container in the user's container storage as btrfs assumes but don't see it. Only container's pre-declared mount points have to be not a snapshot |
github-actions
bot
added
the
locked - please file new issue/PR
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
When running a simple
podman runcommand, I get an error:Error: open executable: Operation not permitted: OCI permission denied.Steps to reproduce the issue:
podman --log-level=debug run --rm docker.io/klakegg/hugo:0.80.0-ext-alpine-ci hugo versionDescribe the results you received:
Without debug log level:
With debug log level:
Describe the results you expected:
The command should run.
Note that another command such as
podman run --rm mariadb lsworks without problem.Additional information you deem important (e.g. issue happens only occasionally): N/A
Output of
podman version:Output of
podman info --debug: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?
Yes
Additional environment details (AWS, VirtualBox, physical, etc.): N/A
The text was updated successfully, but these errors were encountered: