[Feature Request] Too long to start (skip update?) / UID and GID

[diegoweb]

Hey!

Thanks in advance for providing this container, it's working great!

But I'd like to suggest an environment variable to skip the update process. Why I say this? V-Rising Server doesn't get updated that often, and everytime the host needs to be restarted or if perhaps the server crashes, it takes a long time to get back online. So maybe with a variable to force-skip the update, and only when the sysadmin wants to update the server, it enables/disables a environment variable. This would make as easy as it's in Windows to just start the .bat file and get the server running in seconds.

And for last, I could see the start.sh file has "UID" and "GID" to have the server running root-less. I don't know if this is already implemented correctly (since there's nothing in the readme), but by using those variables I still get this message:

Current default time zone: 'America/Sao_Paulo'
Local time is now:      Sun Jan 28 13:05:09 -03 2024.
Universal Time is now:  Sun Jan 28 16:05:09 UTC 2024.
usermod: user 'docker' does not exist
groupmod: group 'docker' does not exist
Updating V-Rising Dedicated Server files...

So all my exposed folders to this containers are still running root:root. Even though I have this in my stack:

    environment:
      - TZ=America/Sao_Paulo
      - UID=1000
      - GID=1000

I went to my host and did a chown -R myuser:myuser /home/myuser/gameserver/vrising but I'm not sure if this could break something, so that's why I'm asking you here. Maybe if UID and GID is detected, it could chown -R UID:GID the gameserver folder and the save folder that is exposed to the host, so all files would always follow the UID and GID provided in the docker container, if I'm not wrong, that's how linuxserver.io containers work.

[TrueOsiris]

This is an issue with many containers and container images (sorry for the late reply).

If the image is made with uid-gid 1000-1000 AND if you're using an exposed volume (so not managed by docker itself), I found out the way to avoid rights issues is this:

• env vars UID=1000 and GID=1000
• on the host do chown -R 1000:1000 /path/to/exposed/volume.

However, in some container images, setting the uid and gid won't do enough. If they hardcoded the executing user or the rights on some maps to, let's say, user 2000, you're going to have a problem if you don't use the same usernumber on the host for the volume rights. An example of this is Elastic, which uses user 10.000 I believe.