DSM 7.0 Container unable to write to volume

[Foolishness]

I tried to run a docker-compose in Portainer on my DS1515+ and ever since I switched to DSM 7 one of the containers is unable to write to the linked volume. The container restarts endlessly and the logs show:

2022-03-16 14:11:22.763    I Initializing core...
2022-03-16 14:11:22.764    I Loading blockchain from folder /home/monero/.bitmonero/lmdb ...
2022-03-16 14:11:22.785    I Stopping cryptonote protocol...
2022-03-16 14:11:22.785    I Cryptonote protocol stopped successfully
2022-03-16 14:11:22.786    E Exception in main! boost::filesystem::create_directory: Permission denied: "/home/monero/.bitmonero/lmdb"

The volume declaration in my docker-compose.yml is:

volumes:
  /volume1/docker/xmrchain:/home/monero/.bitmonero

What permissions do I need to give to what user/group to make this work? (before switching to DSM 7 I had no issues, but apparently the were changes internally in DSM 7. First I tried this using the 'dockerlimited' method for safety considerations, but even when resetting '/var/run/docker.sock' to the original 'root:root' the container is unable to write to the volume. Giving the parameter '--user=root' makes the exception go away, but still nothing gets written in the volume.)

Can anybody spot where the problem is (and be lavish with information, so Dumbo here learns something ?)

 

[one-eyed-king]

Some images start as root, change folder permissions and execute the main process as restricted user.
Other images stay root all the time, and others start as restricted user from the beginning. At least for the later one, you need to align the owner UID:GID of the folder with the UID:GID used inside the container to execute the process (see dockerhub description for hints!).

Then we have Syno ACL's which can interfere. A process inside the container is not able to access files in a way the Syno ACL's would allow it to access the files - it simply has no idea of Syno ACL's.

Is there a reason you mention docker.sock? The permission on that unix domain socket only set who is allowed to interact with the docker api. Do NOT change the UID:GID or permission mask, unless you exactl know you do. If done wrong, you can lock out the Syno Docker UI or the docker cli client (even for root).

 

[Foolishness]

Is there a reason you mention docker.sock? The permission on that unix domain socket only set who is allowed to interact with the docker api. Do NOT change the UID:GID or permission mask, unless you exactl know you do. If done wrong, you can lock out the Syno Docker UI or the docker cli client (even for root)

No, I just mentioned docker.sock because in my ignorance thought that had something to do with my problem.

Some images start as root, change folder permissions and execute the main process as restricted user.
Other images stay root all the time, and others start as restricted user from the beginning. At least for the later one, you need to align the owner UID:GID of the folder with the UID:GID used inside the container to execute the process (see dockerhub description for hints!).

I just had a peak in the Dockerfile on Github (simple-monerod-docker/Dockerfile at main · sethforprivacy/simple-monerod-docker), and it is as you said:

# Add user and setup directories for monerod
RUN set -ex && adduser -Ds /bin/bash monero \
    && mkdir -p /home/monero/.bitmonero \
    && chown -R monero:monero /home/monero/.bitmonero
USER monero

Found the answer:

it says in the readme that the Dockerfile was pulled from someone else's. There I found this mentioned:

Permission issues​

If experiencing permission issues on the volume-mapped folder these can be solved with a chown like below:

docker run -it --rm -v /etc/monero-blockchain:/home/monero/.bitmonero \
--entrypoint chown --user root lchaia/monerod monero:monero -R /home/monero/.bitmonero