L’erreur de permission était en réalité une confusion de chemins
Un utilisateur de ZimaOS devait modifier le fichier config.php de Nextcloud afin d’ajouter une adresse tailnet aux domaines approuvés. Des commandes telles que chown et usermod n’ont pas aidé, car la première question n’était pas de savoir à qui appartenait le fichier, mais quel espace de noms du système de fichiers la commande utilisait.
La discussion a abouti à une solution après que l’utilisateur a inspecté les points de montage du conteneur Nextcloud. Le même fichier apparaissait à un chemin sur l’hôte ZimaOS et à un autre chemin à l’intérieur du conteneur. Un chemin de conteneur saisi depuis l’hôte ne peut pas fonctionner simplement parce qu’il semble correct dans un guide Nextcloud.
Inspectez le point de montage du conteneur avant de modifier les permissions
Identifiez d’abord le conteneur Nextcloud en cours d’exécution :
docker ps --format "table {{.Names}}\t{{.Image}}"Inspectez ensuite ses points de montage en remplaçant l’espace réservé par le nom réel du conteneur :
docker inspect <nextcloud-container-name> --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'Dans ce cas, la sortie indiquait :
/DATA/AppData/nextcloud/var/www/html -> /var/www/htmlLe côté gauche correspond au chemin sur l’hôte. Le côté droit correspond au chemin tel qu’il est visible depuis le conteneur. Cette correspondance explique pourquoi la modification d’un répertoire sans rapport ou la saisie du chemin du conteneur depuis l’hôte n’a pas résolu le problème.
Utilisez le chemin de l’hôte pour modifier le fichier depuis ZimaOS
Depuis le shell de l’hôte ZimaOS, l’utilisateur a trouvé le fichier à l’emplacement suivant :
/DATA/AppData/nextcloud/var/www/html/config/config.phpLa commande de modification correspondante côté hôte est donc :
vim /DATA/AppData/nextcloud/var/www/html/config/config.phpAvant toute modification, la discussion recommandait de vérifier le fichier ainsi que son répertoire parent :
ls -l /DATA/AppData/nextcloud/var/www/html/config/config.php
ls -ld /DATA/AppData/nextcloud/var/www/html/configLe fichier avait des permissions 640 et appartenait à www-data:www-data. Ces informations sont importantes, mais le véritable blocage restait le contexte du chemin. La réponse déconseillait explicitement d’appliquer des modifications de propriété au hasard avant d’avoir localisé la source réelle du montage bind.
Utilisez le chemin du conteneur uniquement après y être entré
L’autre possibilité consiste à entrer dans le conteneur en cours d’exécution, puis à modifier le fichier à cet endroit :
docker exec -it nextcloud sh
vi /var/www/html/config/config.phpÀ l’intérieur du conteneur, /var/www/html/config/config.php est correct. Depuis l’hôte, ce même chemin fait référence au propre système de fichiers racine de l’hôte, et non au répertoire Nextcloud monté.
L’avertissement de configuration Docker était un problème distinct
docker inspect et docker exec affichaient tous deux un avertissement indiquant que /DATA/.docker/config.json ne pouvait pas être ouvert. La réponse a identifié cela comme un avertissement de configuration de l’interface de ligne de commande Docker, et non comme la cause du problème d’accès au fichier Nextcloud. L’utilisateur a pu continuer une fois la distinction entre le chemin de l’hôte et celui du conteneur comprise.
FAQ
Pourquoi la modification de la propriété n’a-t-elle pas corrigé le fichier de configuration Nextcloud ?
Les commandes étaient appliquées sans avoir préalablement confirmé la véritable source du montage bind. Modifier les permissions du mauvais répertoire sur l’hôte n’a aucun effet sur le fichier situé dans le chemin de données Nextcloud monté.
Faut-il modifier config.php depuis l’hôte ou depuis l’intérieur du conteneur ?
Les deux méthodes peuvent fonctionner. Utilisez le chemin source complet /DATA/AppData/... depuis l’hôte, ou entrez d’abord dans le conteneur et utilisez /var/www/html/.... Ne mélangez pas ces deux contextes de chemin.
