De toestemmingsfout bleek eigenlijk een verwisseling van paden
Een ZimaOS-gebruiker moest Nextclouds config.php bewerken om een tailnet-adres aan de vertrouwde domeinen toe te voegen. Opdrachten zoals chown en usermod hielpen niet, omdat de eerste vraag niet was wie eigenaar van het bestand was, maar welke filesystem-namespace de opdracht gebruikte.
De thread kwam tot een succesvol antwoord nadat de gebruiker de mounts van de Nextcloud-container had gecontroleerd. Hetzelfde bestand verscheen op het ZimaOS-hostsysteem onder het ene pad en in de container onder een ander pad. Een containerpad dat vanaf de host wordt ingevoerd, werkt niet zomaar omdat het er in een Nextcloud-handleiding correct uitziet.
Controleer de containermount voordat je machtigingen wijzigt
Identificeer eerst de actieve Nextcloud-container:
docker ps --format "table {{.Names}}\t{{.Image}}"Controleer vervolgens de mounts en vervang de tijdelijke aanduiding door de werkelijke containernaam:
docker inspect <nextcloud-container-name> --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'In dit geval toonde de uitvoer:
/DATA/AppData/nextcloud/var/www/html -> /var/www/htmlDe linkerkant is het hostpad. De rechterkant is het pad zoals dat vanuit de container wordt weergegeven. Deze koppeling verklaart waarom het wijzigen van een niet-gerelateerde map of het invoeren van het containerpad vanaf de host het probleem niet oploste.
Gebruik het hostpad wanneer je vanuit ZimaOS bewerkt
Vanaf de shell van de ZimaOS-host vond de gebruiker het bestand op:
/DATA/AppData/nextcloud/var/www/html/config/config.phpDe bijbehorende bewerkingsopdracht aan de hostzijde is daarom:
vim /DATA/AppData/nextcloud/var/www/html/config/config.phpVoordat je het bestand bewerkt, raadde de thread aan zowel het bestand als de bovenliggende map te controleren:
ls -l /DATA/AppData/nextcloud/var/www/html/config/config.php
ls -ld /DATA/AppData/nextcloud/var/www/html/configDe waargenomen bestandsmodus was 640 en de eigenaar was www-data:www-data. Die informatie is relevant, maar het uiteindelijke probleem bleef de padcontext. Het antwoord raadde nadrukkelijk af om willekeurig eigenaarschap te wijzigen voordat de daadwerkelijke bind mount was gelokaliseerd.
Gebruik het containerpad pas nadat je de container bent binnengegaan
Je kunt ook de actieve container binnengaan en het bestand daar bewerken:
docker exec -it nextcloud sh
vi /var/www/html/config/config.phpIn de container is /var/www/html/config/config.php correct. Vanaf de host verwijst datzelfde pad naar het eigen rootbestandssysteem van de host en niet naar de aan Nextcloud gekoppelde map.
De Docker-configuratiewaarschuwing was een afzonderlijk probleem
Zowel docker inspect als docker exec gaven een waarschuwing dat /DATA/.docker/config.json niet kon worden geopend. Het antwoord identificeerde dit als een configuratiewaarschuwing van de Docker CLI, niet als de oorzaak van het probleem met de toegang tot het Nextcloud-bestand. De gebruiker kon doorgaan zodra het juiste onderscheid tussen het hostpad en het containerpad duidelijk was.
Veelgestelde vragen
Waarom verhielp het wijzigen van het eigenaarschap het probleem met het Nextcloud-configuratiebestand niet?
De opdrachten werden uitgevoerd zonder eerst het daadwerkelijke bronpad van de bind mount te bevestigen. Machtigingen wijzigen in de verkeerde hostmap heeft geen invloed op het bestand binnen het gemounte Nextcloud-datapad.
Moet config.php vanaf de host of vanuit de container worden bewerkt?
Beide opties werken. Gebruik vanaf de host het volledige bronpad /DATA/AppData/..., of ga eerst de container binnen en gebruik /var/www/html/.... Meng de twee padcontexten niet.
