Storage ist eine der komplexesten und gleichzeitig fragilsten Ebenen im Container-Stack. Fehler in dieser Schicht äußern sich häufig indirekt: Anwendungen reagieren träge, schreiben nicht, starten nicht oder zeigen ungewöhnliche Race-Conditions. Podman – als daemonlose Engine – macht Storage-Diagnose einerseits transparenter, weil keine Daemon-Intermediärschicht existiert, andererseits aber auch detailreicher, weil der Kernel direkt sichtbar wird. Dieses Kapitel beschreibt die Mechanismen des Podman-Storage-Subsystems, typische Fehlerbilder und Schritte zur Analyse.
Container-Storage basiert fast immer auf OverlayFS. Das Konzept ist simpel: ein read-only Image-Layer und ein beschreibbarer Upper-Layer bilden zur Laufzeit ein gemeinsames, virtuelles Dateisystem.
Podman legt die Layer standardmäßig hier ab:
/var/lib/containers/storage/overlay/~/.local/share/containers/storage/overlay/Prinzipieller Aufbau:
Wird eine Datei verändert, landet sie im Upper-Layer; Löschungen werden als „Whiteouts“ repräsentiert.
Die Storage-Daten eines Containers sind über
podman inspect sichtbar:
podman inspect --format '{{.GraphDriver.Data}}' <container>Ergebnis:
UpperDir – beschreibbarer LayerLowerDir – Image-LayerWorkDir – ArbeitsverzeichnisDiese Pfade dienen als Einstiegspunkt für tiefere Analysen.
Häufig fragt man sich: Warum kann der Container nicht schreiben, obwohl Permissions sauber gesetzt sind?
Ursache oft:
:Z oder :z gemountetDiagnose:
ls -lZ <volume-path>Fehlt das container_file_t, wird SELinux die Operation
blockieren.
Probleme zeigen sich durch:
OverlayFS kann bei abrupten Host-Reboots oder vollgelaufenen Partitionen beschädigt werden.
Erkennung:
journalctl -k | grep overlayTypische Meldungen:
overlayfs: upper fs missing
overlayfs: failed to read xattrsLösung: Container recreaten; bei hartnäckigen Fehlern: gesamten Overlay-Bereich bereinigen.
Ein Denkfehler: Wenn ein Pfad sowohl im Image existiert als auch als Volume gemountet wird, „verschwindet“ der Image-Inhalt.
Beispiel:
VOLUME /data
...
podman run -v data:/data appDer Mount überschreibt den Image-Pfad vollständig.
Diagnose:
podman diffWenn Image-Inhalt “verloren” wirkt: wahrscheinlich überschrieben durch ein Volume.
OverlayFS teilt sich Speicher mit dem Host. Ist /var
oder $HOME voll, verhält sich der Container
unberechenbar.
Diagnose:
df -h
du -sh /var/lib/containers/storageOverlayFS meldet ENOSPC, sobald:
Inodes prüfen:
df -ixattrs prüfen (experimentell):
getfattr -d <file>Container-Volumes auf NFS sind ein häufiger Fehlerauslöser – insbesondere bei schreibintensiven Anwendungen.
Symptome:
Diagnose:
dmesg | grep nfsBei Datenbanken im Container ist NFS generell nicht zu empfehlen.
Der Upper-Layer spiegelt alle Laufzeitänderungen wider. Er ist der wichtigste Ort für Storage-Diagnosen.
podman inspect --format '{{.GraphDriver.Data.UpperDir}}' <container>Diesen Pfad kann man direkt betrachten – mit Vorsicht.
Ziele:
.wh.-Präfix)Whiteouts sind entscheidend für Diff-Analysen:
find <upper-layer> -name ".wh.*"Sie zeigen entfernte Dateien an.
LowerDir enthält die Image-Inhalte. Manchmal ist relevant zu sehen, ob eine Datei aus dem Image kommt oder vom Container verändert wurde.
Beispiel:
grep -R test.conf $(podman inspect --format '{{.GraphDriver.Data.LowerDir}}' <container>)Wenn etwas “unerklärlich auftaucht”, liegt es oft im Image-Layer, nicht im Container-Layer.
Volumes sind persistent – und damit fehleranfälliger.
podman volume lspodman volume inspect <volume>Gibt:
Volumes liegen typischerweise unter:
/var/lib/containers/storage/volumes~/.local/share/containers/storage/volumesWenn Anwendungen “keine Daten speichern”, ist das häufigste Problem:
Rootless Storage basiert auf FUSE OverlayFS oder kernelbasierten User-Namespace-Funktionen. Typische Probleme:
Symptome:
Diagnose:
mount | grep fuseRootless Container mappen ihre IDs aus dem Host, z. B.:
100000–165536Wenn Dateien auf dem Host außerhalb dieses Range liegen, sind sie für den Container nicht beschreibbar.
Diagnose:
ls -ln /pfad
grep <user> /etc/subuidIn rootless Umgebungen kann SELinux in manchen Distributionen eingeschränkt wirken – das betrifft Volumes.
Wenn Anwendungen unerwartet langsam sind, liegt es häufig am CoW-Verhalten des OverlayFS.
Symptome:
Messung:
iostat -xz 2Oder containerbezogen:
podman statsWenn das Root-Filesystem zu sehr belastet ist, empfiehlt es sich, Volumes statt UpperDir zu nutzen.
mount – zeigt Overlay- und Volume-Mountsfindmnt – strukturiert nach Dateisystemtypenlsns – zeigt Mount-Namespacesstrace -e trace=file – zeigt Dateisystemzugriffeinotifywait – beobachtet filesystem eventsausearch -m avc – für SELinux-bezogene FehlerTypisches Flowchart zur Diagnose:
:Z/:zStorage Debugging in Podman verlangt ein gutes Verständnis von OverlayFS, Namespace-Isolation, Volume-Handling und Kernel-Interaktionen. Wer diese Mechanismen kennt, kann nahezu jede Fehlerquelle identifizieren — egal ob sie aus Applikationsverhalten, Hostkonfiguration oder Storage-Limits entsteht.