jusito/docker-ttt

Volume and copy addons

voigtan opened this issue · 10 comments

I do not think this is an issue just the lack of knowledge from my part. But when I use volume and add addons with the addons I wish to have on my container when I do a restart / start I get a list of permission denied on all files + folders inside /addons/. is there an easy way to solve this?

I would expect from what you wrote, that the permissions get changed by an other container / software, maybe because you are using the same volume elsewhere too.

  1. Does any other container / software / user use the same volume? Fastdl, ftp, other servers, ...
  2. Can you add informations how you started it?
  3. If you replace the volume name with your TTT volume, does the following command output more as "/home"? docker run -it --rm -v VOLUME:/home alpine:3.12 find /home ! \( -user 10000 \) This command will list every files which doesn't belong to the correct user, for my volumes there is none.
  4. I expect that 3 will output more files, which user/groups owns them? docker run -it --rm -v VOLUME:/home alpine:3.12 ls -lA /home (adjust path for your needs)
  5. Just in case question, how did you add the addons to the container?
  1. This is the only container for this volume
  2. Im currently using the example command on the readme (changed just configs)
docker run -d \
 -p 27015:27015/udp \
 -e SERVER_PORT=27015 \
 -e INSTALL_CSS=true \
 -e WORKSHOP_COLLECTION_ID=123456 \
 -e SERVER_NAME="My Server" \
 -e SERVER_PASSWORD="securepw" \
 -e SERVER_DEFAULT_MAP="ttt_lttp_kakariko_a4" \
 -v TTTDev:/home/steam/serverfiles \
 --name "MyTTTServer" \
 jusito/docker-ttt:gmod_ttt_debian
  1. Yes it looks like it list everything there
  2. if I do it on the addons folder I get the user root root
  3. I opened the volume and uploaded it from my machine to the server

I'm quite sure Im doing this wrong, but how would I do to copy an already setup /addon/ folder from a host computer to a new container without getting these errors?

Small notes which could help:

  1. LGSM doesn't allow root as user, so I expect the files arent initially written as root and changed after it.
  2. LGSM in gmod_ttt_debian is 3 month old and only after the first restart it will update itself (I probably should modify this or update the image in hub more often) this could make problems but iam sure not in this case
  3. Example which worked for me:
docker pull jusito/docker-ttt:gmod_ttt_debian
docker run -d \
 -p 27015:27015/udp \
 -e SERVER_PORT=27015 \
 -e INSTALL_CSS=true \
 -e WORKSHOP_COLLECTION_ID=1895900191 \
 -e SERVER_NAME="My Server" \
 -e SERVER_PASSWORD="securepw" \
 -e SERVER_DEFAULT_MAP="ttt_lttp_kakariko_a4" \
 -v TTTIssue6:/home/steam/serverfiles \
 --name "MyTTTServer" \
 jusito/docker-ttt:gmod_ttt_debian
# waited until start completed:
# docker attach MyTTTServer
# docker exec -it MyTTTServer console 
docker restart
# docker attach MyTTTServer
# docker exec -it MyTTTServer console 

Quick workaround should be:

  1. stop container
  2. run docker run -it --rm -v VOLUME:/home alpine:3.12 chown -R 10000:10000 /home
  3. docker inspect -f "{{.Config.User}}" MyTTTServer should output 10000:10000
  4. restart container

I tried the workaround you wrote but Im not sure if have done something wrong:

checking GitHub module query_gsquery.py...OK
checking GitHub module update_steamcmd.sh...OK
[  OK  ] Updating LinuxGSM gmodserver: Updating functions
[  OK  ] Updating gmodserver: Checking for update: SteamCMD

No update available
* Local build: 5427550
* Remote build: 5427550
* Branch: public
https://steamdb.info/app/4020/

[entrypoint.sh]update / installation done!
[prepareServer.sh]check configurations
[initConfig.sh]Request for replacing hostname to hostname "TestingServer", source is found 1 times
root@server:~# 

and the container just stops

Oh you edited your post:
I opened the volume and uploaded it from my machine to the server
The container is not able to fix permissions because it has no root rights, so you have to set permissions to correct owner if you add files manually. The quick workaround on my last post should work for you. Even if this is working, I would suggest to use the steam workshop list only, because its way easier to handle updates aso.

The crash is issue #4 , thought this is a rare case but if you have it too.
What is the output of docker pull jusito/docker-ttt:gmod_ttt_debian
should be:

gmod_ttt_debian: Pulling from jusito/docker-ttt
Digest: sha256:11815a7ce5d77ed88bd47060e955f9bd37ceba6aaba206c697382d4852aa24de
Status: Image is up to date for jusito/docker-ttt:gmod_ttt_debian

The tag gmod_ttt_debian-develop should fix this, would be great if you could try this.

I get

gmod_ttt_debian: Pulling from jusito/docker-ttt
Digest: sha256:11815a7ce5d77ed88bd47060e955f9bd37ceba6aaba206c697382d4852aa24de
Status: Image is up to date for jusito/docker-ttt:gmod_ttt_debian
docker.io/jusito/docker-ttt:gmod_ttt_debian

I will test the develop version tomorrow and start smaller with just one addon and see what happens.

Thanks for testing

I got the same result in gmod_ttt_debian-develop and start over

The quick workaround on my last post should work for you. Even if this is working, I would suggest to use the steam workshop list only, because its way easier to handle updates aso.

I would agree, but there are addons that I need to edit to get it even working So I do not have this option.

I will do the 10000:1000 option on just the addons folder, my guess is when I ran the docker run -it --rm -v VOLUME:/home alpine:3.12 chown -R 10000:10000 /home I changed to many files + folders that should not have been changed.

  1. Finally could reproduce the crash on my machine, but I have only time tomorrow evening to look into this. If you want to look into this until that yourself I added details below.
  2. Every file in the volume is expected to be owned by at least the user or group with rw and sometimes x rights. And the image default runs only on this user, so if it tries to access any file it doesn't have the permissions, it will probably crash. Because of this you could have weird sideeffects which are hard to debug and very time consuming. But ofc it can work and you can try.

Details:

This is one part of the problem why it fails, for good scripts this options should be used but for a quick and dirty workaround you can uncomment it.

# file initConfig.sh 
set -o errexit # exit on error
set -o nounset # exit if variable is used but not set before
set -o pipefail # exit on pipefail

# Your log output indicates, that one of above is triggered, for nounset there would be an additional output so its errexit or pipefail
# To get a more detailed output use: `-e DEBUGGING=true`
[initConfig.sh]Request for replacing hostname to hostname "TestingServer", source is found 1 times
root@server:~# 

Well, I did the FTP example you had to re-install everything and that works good enough for me :) I would kinda want to extend this setup with my own dockerfile with a COPY command but did not get that working when I played around with it (just want to version control this a bit better).

running now the dev image.