The Permission Error Was Really a Path Mix-Up
A ZimaOS user needed to edit Nextcloud's config.php so a tailnet address could be added to trusted domains. Commands such as chown and usermod did not help because the first question was not who owned the file, but which filesystem namespace the command was using.
The thread reached a successful answer after the user inspected the Nextcloud container mounts. The same file appeared at one path on the ZimaOS host and another path inside the container. A container path entered from the host cannot work simply because it looks correct in a Nextcloud guide.
Inspect the Container Mount Before Changing Permissions
First identify the running Nextcloud container:
docker ps --format "table {{.Names}}\t{{.Image}}"Then inspect its mounts, replacing the placeholder with the actual container name:
docker inspect <nextcloud-container-name> --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'In this case, the output showed:
/DATA/AppData/nextcloud/var/www/html -> /var/www/htmlThe left side is the host path. The right side is the path as seen from inside the container. That mapping explains why changing an unrelated directory or entering the container path from the host did not solve the problem.
Use the Host Path When Editing from ZimaOS
From the ZimaOS host shell, the user found the file at:
/DATA/AppData/nextcloud/var/www/html/config/config.phpThe matching host-side edit command is therefore:
vim /DATA/AppData/nextcloud/var/www/html/config/config.phpBefore editing, the thread recommended checking both the file and its parent directory:
ls -l /DATA/AppData/nextcloud/var/www/html/config/config.php
ls -ld /DATA/AppData/nextcloud/var/www/html/configThe observed file mode was 640 and the owner was www-data:www-data. That information matters, but the final blocker was still the path context. The reply explicitly advised against applying random ownership changes before locating the actual bind mount.
Use the Container Path Only After Entering the Container
The alternative is to enter the running container and edit the file there:
docker exec -it nextcloud sh
vi /var/www/html/config/config.phpInside the container, /var/www/html/config/config.php is correct. From the host, that same path refers to the host's own root filesystem and not the bind-mounted Nextcloud directory.
The Docker Config Warning Was a Separate Issue
Both docker inspect and docker exec printed a warning that /DATA/.docker/config.json could not be opened. The reply identified this as a Docker CLI configuration warning, not the cause of the Nextcloud file-access problem. The user was able to continue once the correct host-versus-container path was understood.
FAQ
Why did changing ownership not fix the Nextcloud config file?
The commands were being applied without first confirming the real bind-mount source. Changing permissions on the wrong host directory does not affect the file inside the mounted Nextcloud data path.
Should config.php be edited from the host or inside the container?
Either can work. Use the full /DATA/AppData/... source path from the host, or enter the container first and use /var/www/html/.... Do not mix the two path contexts.
