Ein kurzer Tipp aus der Praxis, der einem auf RHEL-Derivaten wie AlmaLinux, Rocky oder Fedora garantiert irgendwann begegnet: der pod läuft, die Unix-Rechte am Verzeichnis stimmen – und trotzdem hagelt es beim bind-mount ein trotziges „permission denied“. Schuld ist dann meist nicht podman, sondern SELinux. Schauen wir uns kurz an, wie wir podman bind-mount SELinux sauber zusammenbringen – und wann ein bind-mount überhaupt die richtige Wahl ist.
Erst die Frage: bind-mount oder named volume?
Bevor wir am Label schrauben, lohnt der Blick, ob wir den bind-mount überhaupt brauchen. In den meisten Fällen ist ein named volume nämlich der bequemere Weg: podman verwaltet es selbst, legt es in seinem storage ab und labelt es dabei automatisch korrekt mit container_file_t. Kein SELinux-Gefummel, und ein kube play --replace übersteht es klaglos. Für Datenbanken oder Configs, an die wir von außen ohnehin nicht heranmüssen, ist das die erste Wahl – und genau der Weg, den wir auch beim Automatisieren eines pods nutzen.
Ein bind-mount (in der kube-yaml ein hostPath) spielt seine Stärke dagegen aus, wenn wir ein ganz konkretes, bekanntes Verzeichnis vom Host einbinden wollen: eine bestehende Konfiguration, ein Backup-Laufwerk, ein Datenverzeichnis, das auch außerhalb des Containers gepflegt wird. Kurz gesagt immer dann, wenn wir den Pfad selbst in der Hand behalten wollen und nicht in podmans interner Ablage suchen möchten. Der Preis dafür: auf SELinux-Systemen müssen wir uns selbst um das Label kümmern.
Das SELinux-Label für den bind-mount setzen
Der Grund für das „permission denied“ ist schnell erklärt: unser Host-Verzeichnis trägt per Default irgendein Nicht-Container-Label (etwa var_t oder home_root_t), und der Container darf da schlicht nicht ran. Am schnellsten – aber nur bis zum nächsten restorecon – hilft ein chcon:
sudo chcon -Rt container_file_t /srv/meine-datenDauerhaft – und damit die eigentlich richtige Variante – hinterlegen wir das Label fest in der Policy. So übersteht es auch ein System-Relabel, etwa bei einem Policy-Update. Auf Alma braucht semanage das Paket policycoreutils-python-utils:
sudo semanage fcontext -a -t container_file_t "/srv/meine-daten(/.*)?"
sudo restorecon -Rv /srv/meine-datenKurz zum :Z-Flag
Beim direkten podman run geht es sogar ganz ohne Vorarbeit – da nimmt uns das :Z das Relabeln automatisch ab:
podman run -v /srv/meine-daten:/data:Z registry.bla/app:latestIn der kube-yaml funktioniert dieser Trick allerdings nicht – ein :Z lässt sich dort nicht einfach an den Volume-Namen hängen. kube play vergibt hostPath-Mounts zwar ein geteiltes Label, verlässt sich dabei aber darauf, dass es das Verzeichnis auch umlabeln darf – was rootless nicht immer gegeben ist. Wer auf Nummer sicher gehen will, setzt das Label daher einmal selbst, wie oben mit semanage. Ein :Z aus einem früheren run ist übrigens keine verlässliche Grundlage: es vergibt ein privates, exklusives Label, auf das ein frisch gestarteter pod nicht unbedingt passt.
Und ein Wort der Warnung noch: /home, /etc oder /var niemals pauschal umlabeln – dafür immer ein dediziertes Unterverzeichnis nehmen. Sonst legt man sich schnell andere confinte Dienste auf dem System lahm, und der Ärger ist größer als der Nutzen.
Und auf Debian? AppArmor statt SELinux
Wer das Ganze auf Debian nachstellt und sich wundert, warum bei ihm nie etwas hakt: völlig richtig, denn Debian setzt standardmäßig nicht auf SELinux, sondern auf AppArmor. AppArmor arbeitet pfad- statt label-basiert und funkt beim bind-mount eines Verzeichnisses nicht dazwischen. Das komplette Label-Thema ist dort also schlicht keins – der bind-mount läuft ohne Zutun. Wer allerdings, wie in vielen Homelabs üblich, seinen Host auf einem RHEL-Derivat betreibt, sollte den Handgriff kennen.
Unterm Strich: named volume, wo es geht, bind-mount plus semanage, wo es sein muss. Dann bleibt SELinux scharf und der pod trotzdem zugänglich – und das nächtliche „permission denied“ bleibt aus.