Container volumes that cannot be added due to SELinux context are ignored, instead of presenting the user with an error message.

[Magicrafter13]

Cockpit version: 314
Cockpit-podman version: 86
Podman version: 4.9.4
OS: Fedora Linux 39 (Server Edition)

I'm trying to setup Nextcloud. I got it working fine, but added a Redis container, so I needed to recreate my pod and all its containers from scratch (see #1293). Originally it had /opt/nextcloud/web <=> /var/www/html and /opt/nextcloud/data <=> /var/www/html/data.

Now, when I try to create the new container with these volumes, only the web volume gets setup, the data one is just not there. No matter what combination or order I put them in, it never adds this to the container (thus making it unusable).

This, in and of itself, is not a cockpit-podman bug. However I feel this behavior fits the nature of a bug: it does not throw any errors or warnings, and gives no explanation as to what it doesn't like about the one directory.

Steps to reproduce

I wish I could give steps, but this was a complex series of events that got here. Regardless; this is running on Fedora Server 39 (that was just installed yesterday so everything is fresh, updated, and pretty stock). There are no SELinux access control errors.

---

Edit 1: I had a similar issue with my pihole container, but I fixed it by switching the SELinux context type of the "volume" directory from container_file_t to container_var_lib_t. This fix however, did not work for the Nextcloud container. Still, it seems cockpit-podman may be checking permissions and/or security context, and silently ignoring things it won't be able to access?

Edit 2: (forgive my lack of terminology) I fixed the Nextcloud container creation by changing the context of the volume directory. This time I used chchon -l s0. Originally it was s0:cXXX,cXXX - something to that effect with numbers. I'm going to consider this definitively related to SELinux.

[jelly]

Cockpit version: 314 Cockpit-podman version: 86 Podman version: 4.9.4 OS: Fedora Linux 39 (Server Edition)

I'm trying to setup Nextcloud. I got it working fine, but added a Redis container, so I needed to recreate my pod and all its containers from scratch (see #1293). Originally it had /opt/nextcloud/web <=> /var/www/html and /opt/nextcloud/data <=> /var/www/html/data.

Now, when I try to create the new container with these volumes, only the web volume gets setup, the data one is just not there. No matter what combination or order I put them in, it never adds this to the container (thus making it unusable).

This, in and of itself, is not a cockpit-podman bug. However I feel this behavior fits the nature of a bug: it does not throw any errors or warnings, and gives no explanation as to what it doesn't like about the one directory.

Did you create this with with cockpit-podman?

Steps to reproduce

I wish I could give steps, but this was a complex series of events that got here. Regardless; this is running on Fedora Server 39 (that was just installed yesterday so everything is fresh, updated, and pretty stock). There are no SELinux access control errors.

I don't fully understand this issue, deleting the container should not affect a local path into a container. So I am not sure what the actionable part is for Cockpit-podman.

[Magicrafter13]

Did you create this with cockpit-podman?

Yeah, I don't even know how to use podman cli.

I don't fully understand this issue

I tried to make clear that I don't think cockpit-podman caused anything to happen. I'm pretty sure I broke something with the volumes. My problem is that there's no communication in the UI or even the logs (that I can see) of what went wrong. Why, when I create a container with 2 volumes, do I end up with a container with only 1 volume? Clearly there was some issue, but I'm not able to diagnose since I'm given no information. There are no permission denied popups, or SE Linux errors, it just silently fails to add a volume.

Perhaps this falls under feature request rather than bug?