Beim Umzug meines neuen CMS auf den Server sah zunächst alles richtig aus: Repository geklont, Compose-Datei vorhanden, Container gestartet. Trotzdem passte etwas nicht. Dateien ließen sich nicht bearbeiten oder der Container konnte in einen eingebundenen Ordner nicht schreiben. Der Blick auf den Besitzer erklärte das Problem: Ein Teil des Projekts gehörte root.

Wie Dateien überhaupt bei root landen

Der häufigste Grund ist erstaunlich unspektakulär. Wird ein Repository mit sudo git clone geklont, führt root den Befehl aus. Damit gehören auch die neu angelegten Dateien zunächst root. Das kann bei reinem Programmcode unbemerkt bleiben. Sobald Git, ein Editor oder ein Docker-Container etwas schreiben möchte, tauchen jedoch Meldungen wie „Permission denied“ auf.

Ich schaue deshalb zuerst mit ls -la /opt/mein-projekt nach. In den Spalten hinter den Rechten stehen Besitzer und Gruppe. Noch eindeutiger zeigt ls -ln die numerischen Benutzer- und Gruppen-IDs an.

Zusätzlich prüfe ich mit pwd, ob ich wirklich im erwarteten Verzeichnis stehe. Das klingt banal, verhindert bei rekursiven Befehlen aber eine unangenehme Überraschung. Vorher notiere ich außerdem den bisherigen Besitzer, damit sich eine falsche Änderung nachvollziehbar zurücknehmen lässt.

Den Besitzer gezielt korrigieren

Soll mein normaler Benutzer das Projekt verwalten, kann ich den Besitzer mit sudo chown -R lars:lars /opt/mein-projekt ändern. Benutzername und Pfad müssen natürlich zur eigenen Installation passen. Vor dem Abschicken kontrolliere ich den Pfad lieber ein zweites Mal. Das -R arbeitet rekursiv und ändert alles darunter.

Wichtig ist die Trennung: Der Quellcode darf meinem Verwaltungsbenutzer gehören. Datenbank-, Cache- oder Upload-Ordner müssen dagegen unter Umständen für den Benutzer im Container schreibbar sein. Welcher das ist, lässt sich mit docker compose exec DIENSTNAME id prüfen. Die verfügbaren Dienstnamen zeigt docker compose config --services.

Warum chmod 777 keine Lösung ist

In Foren steht bei Rechteproblemen schnell chmod -R 777. Damit darf praktisch jeder Benutzer lesen, schreiben und ausführen. Das beseitigt die Fehlermeldung vielleicht, öffnet aber unnötig viele Türen. Besser ist es, den richtigen Besitzer zu setzen und nur die tatsächlich benötigten Schreibrechte zu vergeben.

Außerdem sollte nicht der komplette Projektordner für den Webserver schreibbar sein. Bei meinem CMS brauchen vor allem Medien, Datenbankdaten und eventuell ein Cache Schreibrechte. Compose-Dateien, Skripte und Programmcode können enger geschützt bleiben.

Zum Schluss wirklich testen

Nach der Korrektur starte ich die Container neu und kontrolliere docker compose ps sowie docker compose logs --tail=100. Danach folgt ein praktischer Test: ein Bild hochladen, einen Beitrag speichern oder genau die Funktion ausführen, die vorher scheiterte. Erst dann ist das Problem tatsächlich behoben.

Dateirechte haben mich schon beim Fediverse beschäftigt. Der ältere Beitrag Mastodon und die vertrackten Dateirechte zeigt, wie schnell das Thema auch bei einer größeren Anwendung auftaucht.

Titelbild: Jake Walker/Unsplash.