Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Script cannot start as user minecraft (999) #41

Open
cyberops7 opened this issue Jan 1, 2025 · 4 comments · May be fixed by #43
Open

Script cannot start as user minecraft (999) #41

cyberops7 opened this issue Jan 1, 2025 · 4 comments · May be fixed by #43
Assignees
@TheRemote

Comments

@cyberops7
Copy link

cyberops7 commented Jan 1, 2025 •
edited
Loading

The change to the script to run as the minecraft user (instead of root) is a good idea, but since the minecraft user is not created in the Dockerfile, if you try to have the container run as user 999 (which appears to be the UID of the minecraft user created by the startup script), the script fails at line 85 since that user does not exist (since it is not running as user 0, it skips the creation of the minecraft user), giving this error:

whoami: cannot find name for user ID 999

The Dockerfiles need to be updated to create the minecraft user, and could really just have the user set to minecraft at the end of the script, something like this (I have not tested it yet):

RUN useradd -m -r -u 999 -g 999 -s /bin/bash minecraft
...
USER minecraft

Sidebar: I find it a bit odd to create a system user (the -r flag) but then give it a shell (the -s flag) since usually system users wouldn't get a shell (but this is how the startup script currently does it, with -r and -s). What is the reason for creating this as a system account, vs a regular account and ending up with a UID > 1000? I just added the -u and -g flags in the example code to be explicit.
@cyberops7
Copy link
Author

At least, that is the error I get when I tried to update my kubernetes manifests for this with:

     securityContext:
       runAsUser: 999
       runAsGroup: 999

@cyberops7
Copy link
Author

A downside to this is that now the process to take ownership of all the files happens twice...once when it creates the minecraft user, and then again when it restarts and gets to the main step where it takes ownership of all files (where it throws an error if you try to actually run the container as user 999).

I'll circle back soon and submit a PR for this as well if no one else gets to it.

@cyberops7
Copy link
Author

Man, this is a bit of a rabbit hole...the way this was implemented in the recent PR that got merged is not ideal, and now has everyone's files owned by 999:999, so we kind of need to stick there. To actually get this done what I would consider the "right" way, where it is also compatible with people's servers that are currently running as root, it is a bit more involved.

Also, a side effect of running the container as a non-root user (which is a best practice) the idea of taking ownership of all files inside the directory may not work as expected, since that will execute as a non-root user now, so if root owns anything, that won't be able to be changed.

@cyberops7
Copy link
Author

I've been working on this, plus tweaking the majority of startup script as part of it...so I'll have a good-sized PR coming soon.

@cyberops7 cyberops7 linked a pull request Jan 4, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@TheRemote TheRemote

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Overhaul of start.sh and Dockerfiles cyberops7/minecraft-server
2 participants
@TheRemote @cyberops7