Impossible to write in the file directory /var/nextdata

[valentincauro]

Impossible to write in the file directory /var/nextdata

[zilexa]

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:

1. 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.

2. 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.