Impossible to write in the file directory /var/nextdata
valentincauro opened this issue · comments
that message is clearly a permissions + ownership + existence issue, nothing wrong with the nextcloud compose file.
To solve: Make sure the directory exist, fix ownership + permissions of that dir AND its parent dir, delete the containers+non-persistent volumes.
Then you have a few things you should verify before running compose up:
- Instead of that line in caddy, to prevent issues arising in case Caddy actually requires several of the volumes of Nextcloud, I would recommend to test first with
volumes_from:
- nextcloud
I have updated the nextcloud.yml to reflect this: https://github.com/zilexa/Homeserver/blob/master/docker/Extras/nextcloud.yml#L18
This way you are absolutely certain the issue is not with Caddy since it has full access to all Nextcloud volumes required to serve content.
- Use the "config" argument instead of up. (see my main docker compose file, the command at the top) to verify the actual path of your $DOCKERDIR). You can then see the full path of the directories as they will all be parsed (including your . ) without actually doing anything (like a dryrun). Verify the paths are all correct.
Regarding the directory you use:
I think I did something wrong with the $DOCKERDIRECTORY variable, I'd just put "." to stay in my root directory (and be able to do data backup later)
I don't really understand what you mean, could you elaborate?
In my case, the docker dir for persistent volumes is: /home/username/docker
and each docker service has a subfolder in there, for example /home/username/docker/nextcloud
. Why are you putting the persistent volumes of a single docker service in your main dir? That will become a mess (plus gives you less ways to fix permissions).
For backup, you can easily backup your $HOME dir (which is /home/username) or your docker dir (which is /home/username/docker
). In my case both are seperate BtrFS subvolumes, making snapshotting instant, they become read-only automatically and allowing very fast incremental backup to backup disks. See my backup guide.
If you are actually using /root
, you have opened a can of worms and I can't really help you as permissions will be completely different, note you should not need to use /root
and you should not need to use sudo when you run docker commands.