El error de permisos era en realidad una confusión de rutas
Un usuario de ZimaOS necesitaba editar el archivo config.php de Nextcloud para añadir una dirección de tailnet a los dominios de confianza. Comandos como chown y usermod no ayudaron porque la primera pregunta no era quién era el propietario del archivo, sino qué espacio de nombres del sistema de archivos estaba utilizando el comando.
El hilo llegó a una respuesta satisfactoria después de que el usuario inspeccionara los montajes del contenedor de Nextcloud. El mismo archivo aparecía en una ruta en el host de ZimaOS y en otra dentro del contenedor. Una ruta del contenedor introducida desde el host no puede funcionar simplemente porque parezca correcta en una guía de Nextcloud.
Inspecciona el montaje del contenedor antes de cambiar los permisos
Primero, identifica el contenedor de Nextcloud en ejecución:
docker ps --format "table {{.Names}}\t{{.Image}}"Después, inspecciona sus montajes y reemplaza el marcador de posición por el nombre real del contenedor:
docker inspect <nextcloud-container-name> --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'En este caso, la salida mostraba:
/DATA/AppData/nextcloud/var/www/html -> /var/www/htmlEl lado izquierdo es la ruta del host. El lado derecho es la ruta tal como se ve desde dentro del contenedor. Esta asignación explica por qué cambiar un directorio no relacionado o introducir la ruta del contenedor desde el host no resolvía el problema.
Usa la ruta del host al editar desde ZimaOS
Desde el shell del host de ZimaOS, el usuario encontró el archivo en:
/DATA/AppData/nextcloud/var/www/html/config/config.phpPor tanto, el comando de edición correspondiente en el host es:
vim /DATA/AppData/nextcloud/var/www/html/config/config.phpAntes de editar, el hilo recomendaba comprobar tanto el archivo como su directorio principal:
ls -l /DATA/AppData/nextcloud/var/www/html/config/config.php
ls -ld /DATA/AppData/nextcloud/var/www/html/configEl modo observado del archivo era 640 y el propietario era www-data:www-data. Esa información es importante, pero el bloqueo final seguía siendo el contexto de la ruta. La respuesta recomendaba explícitamente no aplicar cambios de propietario al azar antes de localizar el origen real del montaje de enlace.
Usa la ruta del contenedor solo después de entrar en él
La alternativa es entrar en el contenedor en ejecución y editar el archivo allí:
docker exec -it nextcloud sh
vi /var/www/html/config/config.phpDentro del contenedor, /var/www/html/config/config.php es correcto. Desde el host, esa misma ruta apunta al propio sistema de archivos raíz del host y no al directorio de Nextcloud montado mediante enlace.
La advertencia de configuración de Docker era un problema independiente
Tanto docker inspect como docker exec mostraban una advertencia indicando que no se podía abrir /DATA/.docker/config.json. La respuesta identificó esto como una advertencia de configuración de la CLI de Docker, no como la causa del problema de acceso al archivo de Nextcloud. El usuario pudo continuar una vez que entendió la diferencia entre la ruta del host y la del contenedor.
Preguntas frecuentes
¿Por qué cambiar el propietario no solucionó el archivo de configuración de Nextcloud?
Los comandos se aplicaron sin confirmar primero el origen real del montaje de enlace. Cambiar los permisos del directorio equivocado del host no afecta al archivo situado dentro de la ruta de datos montada de Nextcloud.
¿Se debe editar config.php desde el host o desde dentro del contenedor?
Cualquiera de las dos opciones puede funcionar. Usa la ruta de origen completa /DATA/AppData/... desde el host, o entra primero en el contenedor y utiliza /var/www/html/.... No mezcles ambos contextos de rutas.
