Du betrachtest gerade Docker PostgreSQL die Falle, unter Docker Desktop und WSL

Docker PostgreSQL die Falle, unter Docker Desktop und WSL

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
  • chmod
  • chown
  • 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:

UmgebungDateisystemLinux-RechtePostgreSQL
WSL /home/...ext4vollständigstabil
WSL /mnt/d/...NTFS via DrvFSteilweise emuliertproblematisch
Windows CMD + Docker DesktopNTFSvirtualisiertoft 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.


Spenden Bild

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 🙏

PayPal Link
Überweisung, Bitcoin und Lightning


#Docker #PostgreSQL #DockerDesktop #SelfHosted #DevOps #Database #WSL2#SysAdmin #Homelab #TechBlog

Dieser Beitrag hat einen Kommentar

Schreibe einen Kommentar