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 Anti-Patterns

chmod -R 777

Das ist der klassische Panik-Move und fast nie die richtige Dauerlösung. Du schwächst damit die Dateirechte auf dem Host und erschwerst spätere Fehlersuche.

Ownership-Modelle beliebig mischen

Wechsle nicht wahllos zwischen:

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

Wähle ein Modell und ziehe es konsequent durch.

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

FAQ

Welche Option ist meistens die richtige?

Für die meisten Setups gilt: beim Standard 1000:1000 bleiben und das Host-Verzeichnis daran anpassen.

Vermeiden Named Volumes einen Teil dieser Probleme?

Ja. Bind Mounts zeigen Host-Rechteprobleme direkter. Named Volumes sind oft einfacher, wenn du nicht direkt auf dem Host an den Dateien arbeiten musst.

Nächste Schritte

• Wenn Schreibzugriffe wieder funktionieren, richte automatische Backups mit docker-mc-backup ein.
• Für Admin-Befehle und sicheren Betrieb nutze RCON und Konsole in Docker.
• Wenn du noch ganz am Anfang bist, prüfe den Hetzner-Docker-Guide.