L’errore di autorizzazione era in realtà un problema di percorsi
Un utente di ZimaOS doveva modificare il file config.php di Nextcloud per aggiungere un indirizzo tailnet ai domini attendibili. Comandi come chown e usermod non sono stati d’aiuto perché la prima domanda non era chi fosse il proprietario del file, ma quale namespace del filesystem stesse utilizzando il comando.
La discussione è arrivata a una soluzione dopo che l’utente ha ispezionato i mount del container Nextcloud. Lo stesso file compariva in un percorso sull’host ZimaOS e in un altro percorso all’interno del container. Un percorso del container inserito dall’host non può funzionare solo perché sembra corretto in una guida di Nextcloud.
Ispeziona il mount del container prima di modificare le autorizzazioni
Per prima cosa, identifica il container Nextcloud in esecuzione:
docker ps --format "table {{.Names}}\t{{.Image}}"Poi ispezionane i mount, sostituendo il segnaposto con il nome effettivo del container:
docker inspect <nextcloud-container-name> --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'In questo caso, l’output mostrava:
/DATA/AppData/nextcloud/var/www/html -> /var/www/htmlIl lato sinistro è il percorso sull’host. Il lato destro è il percorso visibile dall’interno del container. Questa mappatura spiega perché modificare una directory non pertinente o inserire il percorso del container dall’host non abbia risolto il problema.
Usa il percorso dell’host quando modifichi il file da ZimaOS
Dalla shell dell’host ZimaOS, l’utente ha trovato il file in:
/DATA/AppData/nextcloud/var/www/html/config/config.phpIl comando di modifica corrispondente sul lato host è quindi:
vim /DATA/AppData/nextcloud/var/www/html/config/config.phpPrima della modifica, la discussione consigliava di controllare sia il file sia la directory principale:
ls -l /DATA/AppData/nextcloud/var/www/html/config/config.php
ls -ld /DATA/AppData/nextcloud/var/www/html/configLa modalità del file risultava essere 640 e il proprietario era www-data:www-data. Queste informazioni sono importanti, ma il blocco finale era comunque il contesto del percorso. La risposta sconsigliava esplicitamente di applicare modifiche casuali alla proprietà prima di individuare l’origine effettiva del bind mount.
Usa il percorso del container solo dopo esservi entrato
L’alternativa consiste nell’accedere al container in esecuzione e modificare il file al suo interno:
docker exec -it nextcloud sh
vi /var/www/html/config/config.phpAll’interno del container, /var/www/html/config/config.php è corretto. Dall’host, lo stesso percorso fa riferimento al filesystem root dell’host e non alla directory Nextcloud collegata tramite bind mount.
L’avviso sulla configurazione di Docker era un problema separato
Sia docker inspect sia docker exec mostravano un avviso secondo cui non era possibile aprire /DATA/.docker/config.json. La risposta ha identificato il problema come un avviso di configurazione della CLI di Docker, non come la causa del problema di accesso al file di Nextcloud. L’utente ha potuto continuare dopo aver compreso la differenza tra il percorso sull’host e quello nel container.
Domande frequenti
Perché modificare la proprietà non ha risolto il problema del file config.php di Nextcloud?
I comandi venivano applicati senza aver prima verificato l’origine effettiva del bind mount. Modificare le autorizzazioni della directory errata sull’host non influisce sul file all’interno del percorso dei dati Nextcloud collegato.
È meglio modificare config.php dall’host o dall’interno del container?
Entrambe le opzioni possono funzionare. Usa il percorso completo /DATA/AppData/... dall’host oppure accedi prima al container e usa /var/www/html/.... Non mescolare i due contesti di percorso.
