Setup Problem Synology Permission Denied

[hermsluca]

Hi, I am struggling to setup the minecraft server on my Synology DSM 7.3.2.

After setting up the project and starting the container it crashes because of missing folder permissions. This sounds logical but I am struggling to fix this problem for the whole day..

[init] Running as uid=1000 gid=1000 with /data as 'dr-xr-xr-x 1 1000 1000 0 Jun 25 16:51 /data'
[init] Image info: buildtime=2026-06-25T15:22:05.563Z,version=java25,revision=d9bf26cc17115590a805cdb34ee957cc42e8c7c9
/image/scripts/start-utils: line 499: /data/eula.txt: Permission denied
[init] [ERROR] Unable to write eula to /data. Please make sure attached directory is writable by uid=1000 

For now I only went with the latest docker compose template.

I tried to fix this over this guide https://setupmc.com/guides/fix-permission-denied-itzg-docker-minecraft-server/ but this didn't work out, and I was unsure using the common anti pattern.

Something that I also don't understand is why this only happens to this container. Yesterday setting up pihole worked out fine, and it also created entries inside the folder.

many thanks in advance

[itzg]

The directory you're attaching to the container's /data path seems to be read-only. Looking at the first line of output:

[init] Running as uid=1000 gid=1000 with /data as 'dr-xr-xr-x 1 1000 1000 0 Jun 25 16:51 /data'
                                                     ^
                                                     |
                                                     +- this should be a 'w' to indicate it is
                                                        writable for the user with uid=1000

Use chmod to change the permissions or explore some DSM approaches, such as these:

https://share.google/aimode/5586XLE6cTmHjGRsg

[hermsluca]

Hi, thank you very much for your fast response 👌🏼

I got it somehow running now by changing to my admin user with the administrator group id.
I already tried this once, changing the user groups, but I have not changed it to the administration group id.

One thing that I still not understand is why I had to do this, other containers run perfectly fine without any elevated or changed user ids / groups. Also the folder permissions were identical. And they still can write/read to the volume.

[itzg]

Agreed, not sure why the directory permission was any different for this one. Likewise, not sure why yours is the only case (in recent memory) where I have seen the write-permission missing.

Docker containers are just Linux processes declared by the image entry point, so there's infinite possibilities of what particular scripts and executable commands those are using.