UID GID option non root user fails to start

[JoshuaPettus]

Thank you for your awesome work. I saw you had flags for this container to specify a non root user to run the minecraft processes. This is fantastic and what I would do on my bare metal server.

I added the

-e UID=1002 -e GID=1003

to the run command for the respective user and group

Only when I try this on the Bedrock Edition container it wont' run and I get this in the docker log

DEBU[0000] Using /data to match uid and gid
DEBU[0000] Resolved 1002 from environment variable UID
DEBU[0000] Resolved 1003 from environment variable GID
/opt/bedrock-entry.sh: line 44: restify.err: Permission denied /opt/bedrock-entry.sh: line 44: restify.err: Permission denied /opt/bedrock-entry.sh: line 44: restify.err: Permission denied /opt/bedrock-entry.sh: line 44: restify.err: Permission denied /opt/bedrock-entry.sh: line 44: restify.err: Permission denied /opt/bedrock-entry.sh: line 44: restify.err: Permission denied Failed to extract download URL '' from https://www.minecraft.net/en-us/download/server/bedrock/ cat: restify.err: No such file or directory

seems like a file permission error and it needs root?

This worked without a hitch on the Java server so I don't think I'm doing something wrong? Unless I am :)

The container works just fine if I leave the user and group id and let it use root, but I'd rather not if I can get away with it

[itzg]

Are you specifying a volume attachment for /data?

[JoshuaPettus]

Sorry I should have mentioned. I was originally, but that was my first thought too, that I didn't get the permissioning right, so i redid it without the volume and had the same result,

[EDIT] I did it again from scratch making sure to create the volume first with docker run --rm -v mc-volume-be:/data alpine chown 1002:1003 /data

then I did the run command with the UID GID flags and -v mc-volume-be:/data

I know I did this the first time, just wanted to be sure it wasn't some stupid error and wasting your time. Same result I'm afraid.

[itzg]

Are you running on Docker Desktop? If so, you're probably getting the same, weird behavior I see with volume level ownership. On Windows (Docker Desktop WSL2) the chown didn't stick:

docker run --rm -v mc-volume-be:/data alpine ls -al /data
total 8
drwxr-xr-x    2 root     root          4096 Mar 12 19:48 .
drwxr-xr-x    1 root     root          4096 Mar 28 15:32 ..

whereas on my Ubuntu hardware it does:

docker run --rm -v mc-volume-be:/data alpine ls -al /data
total 8
drwxr-xr-x    2 1002     1003          4096 Mar 28 15:33 .
drwxr-xr-x    1 root     root          4096 Mar 28 15:34 ..

So, I actually recommend avoiding explicit use of UID and GID and instead let the entry point match the user to the volume or as you're finding you'll fight ownership inconsitencies.

[JoshuaPettus]

No I'm using docker ubuntu 20.04 on a server That's what I got too:

 docker run --rm -v mc-volume-be:/data alpine ls -al /data
 total 8
 drwxr-xr-x    2 1002     1003          4096 Mar 28 15:42 .
 drwxr-xr-x    1 root     root          4096 Mar 28 15:43 ..

Does the docker container download to somewhere else before writing to /data?

[itzg]

It should do it all to /data, but apparently there's a bug somewhere in here.

[itzg]

I pushed an updated image that outputs info about the running user and the /data ownership and that chown step is definitely not sticking and apparently that is "expected behavior" looking at the closing reason for

https://github.com/moby/moby/issues/3124

IMHO it conflicts with the ability to run containers non-root, but with volumes. The Java edition minecraft server container uses a technique where it runs as root initially, chowns the /data path, and then changes to the requested non-root user.

Even a host directory attached to /data is not honoring the directory ownership, so I'm out of ideas for now how to solve this.

[JoshuaPettus]

Weird...

The Java edition minecraft server container uses a technique where it runs as root initially, chowns the /data path, and then changes to the requested non-root user.

And we can't do that with the BE container? Have it do its setup as root and change the directory to the requested user afterward? Temporary setup is ok as root, its the processes and server itself we want to run as non-root.

As a general rule I always felt it was a bad idea to run anything as root, especially something being connected to directly from the internet, but then this is in a docker container. What is safer running it on bare metal as a non-root, non-loginable user, or run it in a docker container as root?

[itzg]

And we can't do that with the BE container? Have it do its setup as root and change the directory to the requested user afterward? Temporary setup is ok as root, its the processes and server itself we want to run as non-root.

Yes; however, to your next point I was trying to further reduce the process scope running as root, especially running a filesystem modyfing operation like chown. For host mounted volumes, that would be modifying files on the host system as root (via the Docker daemon running as root).

I need to think more about switching to the "old" paradigm used in the java edition image; however, with the awkward behavior of docker volume ownership that might be the only solution.

As a general rule I always felt it was a bad idea to run anything as root, especially something being connected to directly from the internet, but then this is in a docker container. What is safer running it on bare metal as a non-root, non-loginable user, or run it in a docker container as root?

IMHO the two options you listed are equally safe.

[JoshuaPettus]

however, with the awkward behavior of docker volume ownership that might be the only solution.

Yeah, you make some good points and I agree.

IMHO the two options you listed are equally safe.

Great, I won't stress about it too much then! :)

[itzg]

This seems to be slightly more relevant...and still open 🙂

https://github.com/moby/moby/issues/2259

[JoshuaPettus]

Actually I think this article sheds some more light on the situation https://blog.gougousis.net/file-permissions-the-painful-side-of-docker/

Though I havn't yet gotten it to work. I would think the ACL trick would be the answer.

[JoshuaPettus]

In the mean time, I can run the container as root, let it download, then stop and rm the container, manually change the owner of _data in the volume from the host os and then run the docker container with the uid and gid options. it's under /var/lib/docker/volumes/volume_name