-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error: open executable: Operation not permitted: OCI permission denied #9377
Comments
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 entrypoint if it is == [""] containers#9377 Signed-off-by: Daniel J Walsh <[email protected]>
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 <[email protected]>
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 |
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
When running a simple
podman run
command, 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 version
Describe 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 ls
works 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 podman
orapt 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: