Permission denied: Dateirechte für Minecraft in Docker korrigieren

Woran du das Problem erkennst

Dieser Guide ist für den typischen Bind-Mount-Fehler in Docker:

• der Container startet, kann aber unter /data nicht schreiben
• Plugins, Configs oder Welt-Dateien lassen sich nicht aktualisieren
• in den Logs taucht Permission denied auf

Bei itzg/minecraft-server steckt fast immer derselbe Grund dahinter:

Die Besitzrechte auf dem Host passen nicht zu dem Benutzer, unter dem Minecraft im Container läuft.

Warum das passiert

Standardmäßig wechselt das Image auf UID 1000 und GID 1000. Wenn dein gemountetes Host-Verzeichnis einem anderen Benutzer oder einer anderen Gruppe gehört, scheitern Schreibzugriffe.

Das passiert häufig, wenn:

• das Verzeichnis ursprünglich als root angelegt wurde
• der Server von einem anderen Host migriert wurde
• dein Host-Benutzer eine andere UID als 1000 hat

Der schnelle Fix

Wenn du beim Standard-User bleiben willst, korrigiere die Ownership auf dem Host:

sudo chown -R 1000:1000 ./data

Danach Stack neu anwenden oder neu starten:

docker compose up -d

Option 1: Beim Standard bleiben und den Host anpassen

Das ist die einfachste und in den meisten Fällen auch die sinnvollste Variante für einen einzelnen Server.

Compose:

services:
  mc:
    image: itzg/minecraft-server:latest
    volumes:
      - ./data:/data

Host-Fix:

sudo chown -R 1000:1000 ./data
find ./data -maxdepth 2 -ls | head

So bleibst du beim dokumentierten Standard des Images.

Option 2: Den Container an den Host-Benutzer anpassen

Wenn das Host-Verzeichnis bewusst einem anderen Benutzer gehören soll, setze UID und GID explizit:

services:
  mc:
    image: itzg/minecraft-server:latest
    environment:
      UID: "1001"
      GID: "1001"
    volumes:
      - ./data:/data

Das ist nützlich, wenn du auf dem Host bereits ein klares Ownership-Schema etabliert hast.

Option 3: Compose user nur bewusst einsetzen

Docker unterstützt auch ein Compose-weites user::

services:
  mc:
    user: "1001:1001"

Das funktioniert, greift aber breiter in das Laufzeitverhalten des Containers ein. Wenn du nur das dokumentierte Ownership-Modell des Images sauber nachziehen willst, sind UID und GID meist klarer.

Wie du den Fix validierst

Nach dem Neustart:

docker compose logs -f

Du willst einen normalen Start ohne wiederholte Permission-Fehler sehen. Teste danach gezielt einen Schreibpfad, zum Beispiel:

• server.properties ändern
• ein Plugin hinzufügen
• per RCON save-all auslösen

Wenn der Server unter /data Dateien anlegen und ändern kann, ist das Problem gelöst.

Häufige Fehler

chmod -R 777

Mit 777 erlaubst du allen Benutzern Schreibzugriff. Korrigiere stattdessen die Besitzer- und Gruppenrechte des betroffenen Verzeichnisses.

Ownership-Modelle beliebig mischen

Wechsle nicht wahllos zwischen:

• Standard 1000:1000
• benutzerdefiniertem UID/GID
• Compose user

Verwende dieselben Benutzer- und Gruppen-IDs für Container und Datenverzeichnis.

SELinux- oder Rootless-Sonderfälle übersehen

Wenn du Podman oder ein SELinux-lastiges System nutzt, kann der Mount zusätzlich Labels wie :Z brauchen. Das ist dann aber ein anderes Fehlerbild als ein reines UID/GID-Mismatch.

Troubleshooting