Velocity proxy won't start after latest update anymore

[jdevrie]

Expected Behavior
it must start!!

Actual Behavior
Latest version replaces .jar file with new version and can then not access that file itself. It worked until I replaced the docker image today.

Here the log messages:

2026/05/11 14:12:08,stdout,Error: Unable to access jarfile ./velocity-3.5.0-SNAPSHOT-595.jar
2026/05/11 14:12:08,stdout,[init] Setting initial memory to 2048m and max to 2048m
2026/05/11 14:12:07,stdout,[init] Replacing env variables in configs that match the prefix CFG_...
2026/05/11 14:12:07,stdout,�[0;39m[init] /server/forwarding.secret already exists
2026/05/11 14:12:07,stdout,�[39m[mc-image-helper] 12:12:07.019 INFO : The file /server/velocity.toml already exists
2026/05/11 14:12:04,stdout,"�[0;39m[init] Downloading default top-level configs, if needed
"
2026/05/11 14:12:04,stdout,�[0;39m�[39m[mc-image-helper] 12:12:04.231 INFO : Removing old file velocity-3.5.0-SNAPSHOT-594.jar
2026/05/11 14:12:04,stdout,�[39m[mc-image-helper] 12:12:04.221 INFO : Downloaded ./velocity-3.5.0-SNAPSHOT-595.jar
2026/05/11 14:12:00,stdout,[init] Resolving type given VELOCITY

Steps to Reproduce
NA

Plugin List
viaversion 5.9.0
viabackward 5.9.0

Velocity Version
see log messages

Additional Information
No response

[jdevrie]

I changed my execution command in de the docker container to velocity-3.5.0-SNAPSHOT-595.jar and now it works. It seems like some one changed the path of the jar file and added ./

[jdevrie]

This is the new code that fucks up the excution of the jar file because it makes an error in the setting the user . It tries to use user bungeecord but that user is not able to access the jar file:

if ! isTrue "${SKIP_PRIVILEGE_DROP}" && [ "$(id -u)" = 0 ]; then
runAsUser=bungeecord
runAsGroup=bungeecord
log "UID=$PUID"
if [[ $PUID != 0 ]]; then
if [[ $PUID != $(id -u bungeecord) ]]; then
log "Changing uid of bungeecord to $PUID"
usermod -u $PUID bungeecord
fi
else
runAsUser=root
fi

if [[ $PGID != 0 ]]; then
if [[ $PGID != $(id -g bungeecord) ]]; then
log "Changing gid of bungeecord to $PGID"
groupmod -o -g "$PGID" bungeecord
fi
else
runAsGroup=root
fi

if isFalse "${SKIP_CHOWN_DATA}" && [[ $(stat -c "%u" $BUNGEE_HOME) != "$PUID" ]]; then
log "Changing ownership of $BUNGEE_HOME to $PUID ..."
chown -R ${runAsUser}:${runAsGroup} $BUNGEE_HOME
fi

if [[ $runAsUser == root && $runAsGroup == root ]]; then
exec "$JAVA_HOME/bin/java" $JVM_XX_OPTS $JVM_OPTS -jar "$BUNGEE_JAR" "$@"
else
exec runuser -u ${runAsUser} -g ${runAsGroup} -- "$JAVA_HOME/bin/java" $JVM_XX_OPTS $JVM_OPTS -jar "$BUNGEE_JAR" "$@"
fi
else
exec "$JAVA_HOME/bin/java" $JVM_XX_OPTS $JVM_OPTS -jar "$BUNGEE_JAR" "$@"
fi

[jdevrie]

The code above does not test whether the env variables PUID en PGID exist and that is why it took user 1000 which does not exist on a synology NAS. On a synology NAS user numbers start from 1024 when the NAS is initially installed.
It should check the existence of PUID en PGID in the environment first. If they don't exist just run as the current user as it used to do before this change.

[itzg]

@PhoenixmitX can you help out with this?

Related to #319

[PhoenixmitX]

Running on a user with a uid that doesn't exist on the host system is usually no problem.

I think it actually broke from the change of

if [ $UID == 0 ]; then
  chown -R bungeecord:bungeecord $BUNGEE_HOME  # always ran when root
fi

to

if isFalse "${SKIP_CHOWN_DATA}" && [[ $(stat -c "%u" $BUNGEE_HOME) != "$PUID" ]]; then
    chown -R ${runAsUser}:${runAsGroup} $BUNGEE_HOME
fi

Since it now only runs chown, when the root directory has a different user.

When you start the container for the first time it sets the user of all files recursively. But when you restart it and it redownload the jar, then skips the chown (since the root dir still has the right permissions) then the jar itself ends up with user root, resulting in a permission error.

In the previous version the user was always set recursively to uid 1000 (which maps inside the container to the bungeecord user and may map on the host machine to something else).

Hope that analysis is correct, I did it from my phone.
I would have time to investigate deeper/submit a fix for it tomorrow evening (UTC+2, German time).

[PhoenixmitX]

The PUID/PGID are new env cars, that if you don't touch them should behave exactly like it did previously. You could use them to map the containers user to a real user on your nas/host machine.
But it would not fix the current issue of the jar not being chowned.

[itzg]

Thanks @PhoenixmitX

I'm also wondering if we should have it skip user switching if the container was started as a non-root user. Or maybe that's there and similarly I'm not seeing it properly on my phone.

[PhoenixmitX]

The [ "$(id -u)" = 0 ] check means the entire user-switching block is skipped when the container is already running as a non-root user. So that part should be fine.

if ! isTrue "${SKIP_PRIVILEGE_DROP}" && [ "$(id -u)" = 0 ]; then
  # privilege drop logic
else
  exec "$JAVA_HOME/bin/java" ...  # non-root goes straight here
fi

[jdevrie]

The PUID/PGID are new env cars, that if you don't touch them should behave exactly like it did previously. You could use them to map the containers user to a real user on your nas/host machine. But it would not fix the current issue of the jar not being chowned.

That is not completely right. I fixed the problem by changing the UID and GID environment variables to PUID and PGID.

[PhoenixmitX]

Im not completely sure what you mean by that.
Can you provide us wich your docker compose/docker run command?

Also I think that what you changed caused to recursively chmod once (since the uid of the home file didn't match the expacted one). If the container downloads a new velocity build it should have the same issue again.

[jdevrie]

@PhoenixmitX I had two environment variables called UID and GID (which propbably had no function at all) and since there was no PUID or PGID the code would react by ending up using the userid 1000 that does not exist on Synology NASses. When I changed the name of those environment variables to PUID and PGID the code did retrieve them and it ended up using the userid that was in varaiable PUID.

What you need to update is that if there are no PUID and PGID environment variables that you just act as in the previous verison of the code without switching to another userid away from root.

I just did a little test and forced the code to redownload the jar file and it had no problems whatsoever after the download.
That is logical since the userid used was the one I provided in PUID which was the original userid that it ran with before the l.atest code update.

Here the log of the download test:

2026/05/12 13:48:46,stdout,[11:48:46 INFO] [viaversion]: Replacing channel initializers; you can safely ignore the following two warnings.
2026/05/12 13:48:45,stdout,[11:48:45 INFO] [viaversion]: Loading block connection mappings ...
2026/05/12 13:48:45,stdout,[11:48:45 INFO]: Loaded 3 plugins
2026/05/12 13:48:45,stdout,"[11:48:45 INFO]: Loaded plugin viabackwards 5.9.1 by Matsv, kennytv, Gerrygames, creeper123123321, ForceUpdate1, EnZaXD
2026/05/12 13:48:45,stdout,"[11:48:45 INFO]: Loaded plugin viaversion 5.9.1 by MylesC, creeper123123321, Gerrygames, kennytv, Matsv, EnZaXD, RK_01"
2026/05/12 13:48:44,stdout,[11:48:44 INFO]: Loading plugins...
2026/05/12 13:48:44,stdout,[11:48:44 INFO]: Loading localizations...
2026/05/12 13:48:44,stdout,"[11:48:44 INFO]: Connections will use epoll channels, libdeflate (Linux x86_64) compression, OpenSSL 3.x.x (Linux x86_64) ciphers
2026/05/12 13:48:43,stdout,[11:48:43 INFO]: Booting up Velocity 3.5.0-SNAPSHOT (git-9c0c9b02-b595)...
2026/05/12 13:48:42,stdout,[init] Setting initial memory to 2048m and max to 2048m
2026/05/12 13:48:41,stdout,[init] Replacing env variables in configs that match the prefix CFG...
2026/05/12 13:48:41,stdout,�[0;39m[init] /server/forwarding.secret already exists
2026/05/12 13:48:40,stdout,�[39m[mc-image-helper] 11:48:40.754 INFO : The file /server/velocity.toml already exists
2026/05/12 13:48:38,stdout,"�[0;39m[init] Downloading default top-level configs, if needed
2026/05/12 13:48:37,stdout,�[39m[mc-image-helper] 11:48:37.768 INFO : Downloaded ./velocity-3.5.0-SNAPSHOT-595.jar
2026/05/12 13:48:33,stdout,[init] Resolving type given VELOCITY

[itzg]

@jdevrie it always did the user switching

if [ $UID == 0 ]; then
  exec sudo -E -u bungeecord "$JAVA_HOME/bin/java" $JVM_XX_OPTS $JVM_OPTS -jar "$BUNGEE_JAR" "$@"
else
  exec "$JAVA_HOME/bin/java" $JVM_XX_OPTS $JVM_OPTS -jar "$BUNGEE_JAR" "$@"
fi

It would be great if you could set the env var DEBUG to "true", provide that compose file or equivalent, and the full container startup logs.

@PhoenixmitX , I guess it was too much at this time to bring in anything more than changing sudo to runuser. Can you submit a PR to "revert" the other changes?

With that, users can set the container level "--user" however they want, for example to match the Synology user that owns the mounted directory...and leave users to do their own chown'ing. I'm remembering now that it's precarious to automated that after the fact. That's why my bedrock image doesn't do it.

[itzg]

...or I can revert the other changes if you don't have time.

[PhoenixmitX]

I am currently working.
If you have time now, I think it makes sense if you revert the changes. However I think it would behave exactly like it did before if we would change

  if isFalse "${SKIP_CHOWN_DATA}" && [[ $(stat -c "%u" $BUNGEE_HOME) != "$PUID" ]]; then 
     log "Changing ownership of $BUNGEE_HOME to $PUID ..." 
     chown -R ${runAsUser}:${runAsGroup} $BUNGEE_HOME 
   fi

to

  if isFalse "${SKIP_CHOWN_DATA}"; then 
     log "Changing ownership of $BUNGEE_HOME to $PUID ..." 
     chown -R ${runAsUser}:${runAsGroup} $BUNGEE_HOME 
   fi

I would like to have this tried out before doing a full rewert.

[itzg]

I am currently working.
If you have time now, I think it makes sense if you revert the changes.

I can appreciate that -- this is my 10 minutes to read github issues before I start working.

I'm going to revert all but the runuser change and you can follow up with the proposed adjustment.