Docker PostgreSQL die Falle, unter Docker Desktop und WSL. Nur ein PostgreSQL Update kann reichen und die DB fällt aus. Der Teufel im Detail !
Docker unter Windows wirkt auf den ersten Blick simpel:
Docker Desktop installieren, Container starten, fertig.
Spätestens bei PostgreSQL unter WSL2 merkt man aber, dass hinter den Kulissen zwei völlig unterschiedliche Welten aufeinanderprallen.
Der entscheidende Punkt ist nicht Docker selbst — sondern wie Volumes gemountet werden und welche Dateirechte der Linux-Container tatsächlich sieht.
Video: Docker PostgreSQL die Falle, unter Docker Desktop und WSL
Sprache: 🇩🇪|🇬🇧
☝️ Benutze YouTube Untertitel für alle Sprachen.
Viele starten ihre Container direkt aus:
- WSL-Terminal
- Windows CMD
- PowerShell
…und erwarten identisches Verhalten.
Das ist aber technisch nicht dasselbe.
Unter Docker Desktop laufen Linux-Container intern immer in einer Linux-VM. PostgreSQL erwartet daher:
- echte POSIX-Dateirechte
chmodchown- Linux-UID/GID
- korrektes Filesystem-Verhalten
Jetzt wird es interessant.
Wenn man Docker aus einem WSL-Terminal startet und Daten innerhalb des Linux-Dateisystems liegen (/home/user/...), arbeitet PostgreSQL auf einem echten ext4-Dateisystem.
Alle Linux-Dateirechte funktionieren wie erwartet.
Sobald die Daten aber auf einem Windows-Laufwerk liegen:
/mnt/c/
/mnt/d/
ändert sich alles.
Diese Mounts sind kein echtes Linux-Dateisystem.
WSL benutzt hier eine Übersetzungsschicht zwischen:
- NTFS
- Windows ACLs
- Linux-Permissions
Das funktioniert für normale Dateien oft problemlos.
Datenbanken sind aber extrem empfindlich bei:
- Ownership
- Dateirechten
- fsync
- inode-Verhalten
- Locking
Genau deshalb laufen viele PostgreSQL-Versionen monatelang scheinbar stabil — bis ein Upgrade kommt.
Ein typischer Fall:
- PostgreSQL 14 läuft
- Upgrade auf PostgreSQL 16
- plötzlich:
chmod: Operation not permitted
initdb: could not change permissions
Warum?
Neuere PostgreSQL-Versionen prüfen Rechte deutlich strenger und führen aggressive chmod/chown-Operationen aus.
NTFS über WSL kann diese Linux-Operationen aber nicht vollständig abbilden.
Das Ergebnis:
- Container startet ständig neu
- Datenbank initialisiert nicht
- obwohl dieselbe Struktur vorher funktionierte
Der wichtige Unterschied ist also nicht nur:
- WSL vs Windows CMD
sondern vor allem:
- echtes Linux-Dateisystem vs NTFS-Mount
Vergleich:
| Umgebung | Dateisystem | Linux-Rechte | PostgreSQL |
|---|---|---|---|
WSL /home/... | ext4 | vollständig | stabil |
WSL /mnt/d/... | NTFS via DrvFS | teilweise emuliert | problematisch |
| Windows CMD + Docker Desktop | NTFS | virtualisiert | oft kritisch |
Die wichtigste Erkenntnis:
Auch wenn PostgreSQL als virtualisiert und als oft kritisch ausgewisen wird, stellt es die einzigste Lösung dar eine PostgreSQL stabil ans laufen zu bekommen.
Docker abstrahiert Container — aber nicht die Realität des Dateisystems darunter.
Und genau dort scheitern viele Datenbank-Setups unter Windows.

Link zur Unterstützung / Spende für den Kanal
Wenn meine Beiträge hilfreich sind oder dir geholfen haben, würde ich mich über eine Unterstützung sehr freuen 🙏
#Docker #PostgreSQL #DockerDesktop #SelfHosted #DevOps #Database #WSL2#SysAdmin #Homelab #TechBlog
Pingback: PostgreSQL Update auf Version.16, Major Upgrade inks. Datenübernahme | Michael Klissner