podman: container fails to start with: failed to mount shm tmpfs: invalid argument
I have a container that runs fails to start with failed to mount shm ... : invalid argument.
The container used to start before.
# podman start gogs
Error: unable to start container "dcc001e4a20629902cef7a73683d8efb7ceaef0863049a717e6c0b75e0d7cacf": failed to mount shm tmpfs "/var/lib/containers/storage/overlay-containers/dcc001e4a20629902cef7a73683d8efb7ceaef0863049a717e6c0b75e0d7cacf/userdata/shm": invalid argument
[
Some info about the container:
It runs gogs: https://hub.docker.com/r/gogs/gogs.
One volume is mounted to an NFS folder. This is the /data volume, so probably not related to the error.
The container gets started as the root user on a Fedora 36 VM.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 2
- Comments: 22 (19 by maintainers)
Hold on a second. I just realised that refpolicy has its own
containermodule these days!I just built/installed, re-enabled container labelling, and Podman now works again!
(Hopefully this will contribute to preservation of Dan’s tears…)
I don’t know how refpolicy’s module compares to container-selinux’s module, but since it passed a smoke test I’ll ask Debian to include it in
selinux-policy-default.Which makes me cry. :^) https://stopdisablingselinux.com/
If you dont’ have container-selinux installed SELinux separation will not work, and I don’t believe that container-selinux will install without using fedora selinux-policy. So you would be best to remove /usr/share/containers/selinux/contexts
and see if this works, if it blows up then you might need to just set all the fields in that file to “”, and see if that works. Otherwise you should disable SELinux separation in the containers.conf file.
If SELinux is disabled on the system, the SELinux container configuration could be ignored instead of causing the container to stop working.
It’s counter-intuitive (to me) that something stops working when SELinux gets disabled.
Anyway, now that I know what the cause is, I’ve re-created my container and it’s working fine.
Guaranteed that it what this is. Basically the context=“…” is blowing on on a non SELinux machine.
One potential idea. Do you have SELinux enabled on your system? If not, you created this container before when SELinux was enabled and now are running with SELinux disabled.