Hey @mattlorimor
I like this change but would it be possible to also add uID and gID like e. g. TS3 Docker Image did it (9987)?

Because when I add a volume linked to the /home path and upload the file, it is done as root user and I am not sure if things then go well if the file isn't changed to the correct uID/gID outside the container, e. g. for write access or doesn't this matter?

Ugh, so I had merged this, but had to make a commit to undo it. When I was testing, I was getting a lot of crashing due to tshock failing permissions to write to a volume. After some googling, I think it is related to moby/moby#2259 (comment).

No matter what I did to change the permissions on directories that are volumed, they are stuck at root. My linux-foo isn't the strongest though so maybe you guys have a better idea?

@ryansheehan - What did the docker run command you were using look like? I'm going to try to replicate this on my end.

docker run --rm -it -p 7777:7777 -v $HOME/Projects/personal/terraria/test/world:/world -v $HOME/Projects/personal/terraria/test/ServerPlugins:/plugins terraria

I dropped a text file into the ServerPlugins directory to test the copy

@ryansheehan

Oddly, I'm not having any issues creating or saving a world when doing this on Windows or my macOS machine.

Additionally, the permissions don't behave exactly the same across my Windows and macOS tests.

ls -alh / on Windows:

ls -alh / on macOS:

Dummy text file gets copied in properly:

Can write to the /world directory:

I have no idea why the VOLUME results in differing permissions between my two systems.

I must be missing something simple, here.

These tests I'm doing are on the following versions of Docker desktop...

Windows:

macOS:

The same permissions discrepancies can be seen with a small, test Dockerfile:

FROM alpine
RUN mkdir /test && \
    chown -R nobody:nobody /test
USER nobody
VOLUME ['/test']

Maybe this could help out: https://github.com/TeamSpeak-Systems/teamspeak-linux-docker-images/blob/master/alpine/Dockerfile#L4-L7 - I have no problems with my TS3-Setup

And this one too: https://github.com/TeamSpeak-Systems/teamspeak-linux-docker-images/blob/master/alpine/entrypoint.sh#L4-L8

Hope, that I could help out a bit :)

Thanks for that, @Chaoschaot232.

It should be easy enough to change the groupadd and useradd to force uid and gid through like this:

RUN groupadd -r -g 999 terraria && \
    useradd -m -r -u 999 -g terraria terraria

And modify all the chowns to 999:999 (or whatever uid/gid).

But I think the issue @ryansheehan is encountering is a little different. I'm trying to understand why it sounds like the container process couldn't even write to the volumes when I'm not seeing the same thing. My run command should be functionally the same:

docker run --name terraria --rm -it -p 7777:7777 -v C:/.terraria2/world:/world -v C:/.terraria2/ServerPlugins:/plugins test

I think, at this point, I'd need to see what Ryan's error output looks like.

And what Docker version they're using and on what system (Windows? macOS? Ubuntu?).

If you get a chance, see if this NonRoot branch of mine does what you want: https://github.com/mattlorimor/terraria-1/tree/NonRoot.

It creates the terraria user in the Dockerfile and runs the Dockerfile as root, but executes the TerrariaServer.exe as the terraria user instead of the privileged root user.

The uid and gid default to 7777, but can be configured by passing UID and GID into the container as environment variables when running it.

I wish I could move this into a new PR. I'm struggling to keep up with all the TShock updates and issues being posted. Oh and Terraria itself released a 1.4.0.3 update! I'll try and take a look at this soon. When I was last trying, on linux, all volumes connected as root, and no amount of chown/chmod was getting me around the permission errors that TerrariaServer.exe was blowing up on.