Molecule SELinux "relabel" / permission denied on mounts in CI

By Kaveh Alemi·Latchkey

On SELinux-enforcing hosts, files bind-mounted into a container are inaccessible unless the mount is relabelled. Molecule tasks that read a mounted path then fail with "Permission denied" despite correct file modes.

What this error means

A converge or verify task fails with "Permission denied" reading a bind-mounted path, and ls -Z shows the wrong SELinux context on the mount.

Molecule

fatal: [instance]: FAILED! => {"msg": "Permission denied", "path": "/opt/app/config.yml"}
# audit log: avc: denied { read } ... scontext=...:container_t tcontext=...:default_t

Common causes

A bind mount was not relabelled for the container

SELinux blocks a container_t process from reading host files whose label it does not own. Without :z/:Z, the mount is denied.

Enforcing mode with a default host context

The runner runs SELinux in enforcing mode and the mounted path keeps its host label, which the container is not allowed to access.

How to fix it

Relabel the volume with :z or :Z

Add the SELinux relabel suffix to the mount so the container may access it (:z shared, :Z private).

molecule/default/molecule.yml

platforms:
  - name: instance
    image: quay.io/centos/centos:stream9
    volumes:
      - ${PWD}/files:/opt/app:Z

Confirm the relabel took effect

Inside the container the path should carry a container-accessible context after the relabel.

Terminal

ls -Z /opt/app

How to prevent it

Add :z/:Z to every bind mount used by SELinux-enforcing runners.
Test scenarios on the same SELinux mode CI uses.
Avoid mounting host paths when a copy into the image suffices.

Frequently asked questions

What causes "SELinux "Permission denied" on volume"?

SELinux blocks a container_t process from reading host files whose label it does not own. Without :z/:Z, the mount is denied.

How do I fix SELinux "Permission denied" on volume?

Add the SELinux relabel suffix to the mount so the container may access it (:z shared, :Z private).