Behörighetsfelet berodde egentligen på en sammanblandning av sökvägar
En ZimaOS-användare behövde redigera Nextclouds config.php för att lägga till en tailnet-adress i betrodda domäner. Kommandon som chown och usermod hjälpte inte, eftersom den första frågan inte var vem som ägde filen, utan vilket filsystemnamnområde kommandot använde.
Tråden nådde ett fungerande svar efter att användaren hade granskat Nextcloud-containerns monteringar. Samma fil fanns på en sökväg på ZimaOS-värden och på en annan sökväg inuti containern. En containersökväg som anges från värden kan inte fungera bara för att den ser korrekt ut i en Nextcloud-guide.
Granska containerns montering innan du ändrar behörigheter
Identifiera först den körande Nextcloud-containern:
docker ps --format "table {{.Names}}\t{{.Image}}"Granska sedan dess monteringar och ersätt platshållaren med det faktiska containernamnet:
docker inspect <nextcloud-container-name> --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'I det här fallet visade resultatet:
/DATA/AppData/nextcloud/var/www/html -> /var/www/htmlDen vänstra sidan är värdens sökväg. Den högra sidan är sökvägen som den visas inuti containern. Den mappningen förklarar varför det inte löste problemet att ändra en orelaterad katalog eller ange containersökvägen från värden.
Använd värdens sökväg när du redigerar från ZimaOS
Från ZimaOS-värdens skal hittade användaren filen här:
/DATA/AppData/nextcloud/var/www/html/config/config.phpDet motsvarande redigeringskommandot på värdsidan är därför:
vim /DATA/AppData/nextcloud/var/www/html/config/config.phpInnan redigering rekommenderade tråden att både filen och dess överordnade katalog skulle kontrolleras:
ls -l /DATA/AppData/nextcloud/var/www/html/config/config.php
ls -ld /DATA/AppData/nextcloud/var/www/html/configDen observerade filbehörigheten var 640 och ägaren var www-data:www-data. Den informationen är viktig, men det slutliga hindret var fortfarande sökvägskontexten. Svaret avrådde uttryckligen från att göra godtyckliga ägarändringar innan den faktiska bind-monteringen hade lokaliserats.
Använd containersökvägen först efter att du har gått in i containern
Alternativet är att gå in i den körande containern och redigera filen där:
docker exec -it nextcloud sh
vi /var/www/html/config/config.phpInuti containern är /var/www/html/config/config.php korrekt. Från värden hänvisar samma sökväg till värdens eget rotfilsystem och inte till den bindmonterade Nextcloud-katalogen.
Docker-konfigurationsvarningen var ett separat problem
Både docker inspect och docker exec visade en varning om att /DATA/.docker/config.json inte kunde öppnas. Svaret identifierade detta som en varning om Docker CLI-konfigurationen, inte som orsaken till problemet med filåtkomsten i Nextcloud. Användaren kunde fortsätta när skillnaden mellan värdens och containerns sökväg hade förståtts.
Vanliga frågor
Varför löste det inte problemet med Nextclouds konfigurationsfil att ändra ägaren?
Kommandona kördes utan att den faktiska källan för bind-monteringen först hade bekräftats. Att ändra behörigheter på fel katalog på värden påverkar inte filen i den monterade Nextcloud-datasökvägen.
Bör config.php redigeras från värden eller inuti containern?
Båda alternativen kan fungera. Använd den fullständiga källsökvägen /DATA/AppData/... från värden, eller gå först in i containern och använd /var/www/html/.... Blanda inte ihop de två sökvägskontexterna.
