Der Berechtigungsfehler war tatsächlich eine Pfadverwechslung
Ein ZimaOS-Benutzer musste die config.php von Nextcloud bearbeiten, um eine Tailnet-Adresse zu den vertrauenswürdigen Domains hinzuzufügen. Befehle wie chown und usermod halfen nicht, weil die erste Frage nicht lautete, wem die Datei gehört, sondern welchen Dateisystem-Namensraum der Befehl verwendete.
Der Thread führte zu einer erfolgreichen Lösung, nachdem der Benutzer die Container-Mounts von Nextcloud überprüft hatte. Dieselbe Datei erschien unter einem Pfad auf dem ZimaOS-Host und unter einem anderen Pfad innerhalb des Containers. Ein im Host verwendeter Container-Pfad kann nicht funktionieren, nur weil er in einer Nextcloud-Anleitung korrekt aussieht.
Vor der Änderung von Berechtigungen den Container-Mount prüfen
Zuerst den laufenden Nextcloud-Container ermitteln:
docker ps --format "table {{.Names}}\t{{.Image}}"Anschließend die Mounts überprüfen und den Platzhalter durch den tatsächlichen Containernamen ersetzen:
docker inspect <nextcloud-container-name> --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'In diesem Fall zeigte die Ausgabe:
/DATA/AppData/nextcloud/var/www/html -> /var/www/htmlDie linke Seite ist der Host-Pfad. Die rechte Seite ist der Pfad, wie er innerhalb des Containers sichtbar ist. Diese Zuordnung erklärt, warum das Ändern eines nicht zugehörigen Verzeichnisses oder die Verwendung des Container-Pfads auf dem Host das Problem nicht löste.
Beim Bearbeiten über ZimaOS den Host-Pfad verwenden
In der ZimaOS-Host-Shell fand der Benutzer die Datei unter:
/DATA/AppData/nextcloud/var/www/html/config/config.phpDer passende Bearbeitungsbefehl auf der Host-Seite lautet daher:
vim /DATA/AppData/nextcloud/var/www/html/config/config.phpVor der Bearbeitung empfahl der Thread, sowohl die Datei als auch ihr übergeordnetes Verzeichnis zu überprüfen:
ls -l /DATA/AppData/nextcloud/var/www/html/config/config.php
ls -ld /DATA/AppData/nextcloud/var/www/html/configDer festgestellte Dateimodus war 640, und der Besitzer war www-data:www-data. Diese Informationen sind wichtig, doch der eigentliche Blocker war weiterhin der Pfadkontext. In der Antwort wurde ausdrücklich davon abgeraten, zufällige Änderungen an den Besitzverhältnissen vorzunehmen, bevor der tatsächliche Bind-Mount ermittelt wurde.
Den Container-Pfad nur innerhalb des Containers verwenden
Alternativ kann man den laufenden Container öffnen und die Datei dort bearbeiten:
docker exec -it nextcloud sh
vi /var/www/html/config/config.phpInnerhalb des Containers ist /var/www/html/config/config.php korrekt. Auf dem Host verweist derselbe Pfad jedoch auf das eigene Root-Dateisystem des Hosts und nicht auf das per Bind-Mount eingebundene Nextcloud-Verzeichnis.
Die Docker-Konfigurationswarnung war ein separates Problem
Sowohl docker inspect als auch docker exec gaben eine Warnung aus, dass /DATA/.docker/config.json nicht geöffnet werden konnte. In der Antwort wurde dies als Warnung zur Docker-CLI-Konfiguration und nicht als Ursache des Problems beim Dateizugriff auf Nextcloud identifiziert. Der Benutzer konnte fortfahren, sobald der Unterschied zwischen Host- und Container-Pfad verstanden war.
FAQ
Warum hat das Ändern der Besitzverhältnisse die Nextcloud-Konfigurationsdatei nicht repariert?
Die Befehle wurden ausgeführt, ohne zuvor die tatsächliche Quelle des Bind-Mounts zu bestätigen. Das Ändern von Berechtigungen im falschen Host-Verzeichnis wirkt sich nicht auf die Datei im eingebundenen Nextcloud-Datenpfad aus.
Sollte config.php auf dem Host oder innerhalb des Containers bearbeitet werden?
Beides ist möglich. Verwenden Sie auf dem Host den vollständigen Quellpfad /DATA/AppData/... oder öffnen Sie zuerst den Container und verwenden Sie /var/www/html/.... Vermischen Sie die beiden Pfadkontexte nicht.
