Permission issues
timvahlbrock opened this issue · comments
First of all: Thanks for maintaining this container! I'm trying to use this image on a Kubernetes k3s cluster and having problems with the volume permissions. I have added a a user ttt with userid 10000 and configured Kubernetes to use that user to run the container and mount the volume:
---
...
spec:
...
template:
...
spec:
securityContext:
runAsUser: 10000
runAsGroup: 10000
fsGroup: 10000
containers:
- name: docker-ttt
image: jusito/docker-ttt:gmod_ttt_debianI can see the volume getting created, and the ttt user being set as the owner. And it getting filled with the "garrysmod" folder:
However, there still seem to be permission problems. I think when I used static volumes, I solved this by running chmod on the volume folder, but this didn't help now either (even from inside the container). I know that this image is originally designed for bare docker/docker-compose usage, but it would still be awesome if you have an idea on what might be going wrong or can point me in the direction what I need to check again.
The container log
[entrypoint.sh]starting entrypoint.sh [entrypoint.sh]installing... Installed Garrys Mod server as gmodserverRemember to check server ports
./gmodserver details
fetching GitHub core_trap.sh...OK
fetching GitHub _default.cfg...OK
copying _default.cfg...OK
fetching GitHub check_ip.sh...OK
fetching GitHub info_game.sh...OK
fetching GitHub common.cfg...OK
fetching GitHub secrets-common.cfg...OK
fetching GitHub gmodserver.cfg...OK
fetching GitHub secrets-gmodserver.cfg...OK
fetching GitHub linuxgsm.sh...OK
fetching GitHub core_getopt.sh...OK
fetching GitHub command_install.sh...OK
fetching GitHub check.sh...OK
fetching GitHub check_version.sh...OK
[ ERROR ] Installing gmodserver: LinuxGSM version mismatch
- gmodserver: v23.1.0
- modules: v23.2.3
fetching GitHub command_update_linuxgsm.sh...OK
fetching GitHub check_root.sh...OK
fetching GitHub check_tmuxception.sh...OK
fetching GitHub check_permissions.sh...OK
[ FAIL ] Updating LinuxGSM gmodserver: Ownership issues found
Information! The current user (steam) does not have ownership of the following files:
tee: /home/steam/log/script/gmodserver-script.log: No such file or directory
User Group File
root root /home/steam/serverfiles
Information! please see https://docs.linuxgsm.com/support/faq#fail-starting-game-server-permission-issues-found
fetching GitHub core_exit.sh...OK
fetching GitHub check_logs.sh...OK
[ INFO ] Updating LinuxGSM gmodserver: Checking for log files: Creating log files
fetching GitHub install_logs.sh...OK
installing log dir: /home/steam/log...OK
installing LinuxGSM log dir: /home/steam/log/script...OK
creating LinuxGSM log: /home/steam/log/script/gmodserver-script.log...OK
installing console log dir: /home/steam/log/console...OK
creating console log: /home/steam/log/console/gmodserver-console.log...OK
creating symlink to game log dir: /home/steam/log/server -> /home/steam/serverfiles/garrysmod/logs...OK
fetching GitHub info_distro.sh...OK
[ OK ] Updating LinuxGSM gmodserver: Selecting repo: GitHub
checking GitHub linuxgsm.sh...OK
checking gmodserver...UPDATE
backup gmodserver...OK
backup location /home/steam/lgsm/backup/script/gmodserver-09_27_2023_24.bak
copying gmodserver...OK
checking GitHub config _default.cfg...OK
checking GitHub module check.sh...OK
checking GitHub module check_ip.sh...OK
checking GitHub module check_logs.sh...OK
checking GitHub module check_permissions.sh...OK
checking GitHub module check_root.sh...OK
checking GitHub module check_tmuxception.sh...OK
checking GitHub module check_version.sh...OK
checking GitHub module command_install.sh...OK
checking GitHub module command_update_linuxgsm.sh...OK
checking GitHub module core_dl.sh...OK
checking GitHub module core_exit.sh...OK
checking GitHub module core_functions.sh...OK
checking GitHub module core_getopt.sh...OK
checking GitHub module core_legacy.sh...OK
checking GitHub module core_messages.sh...OK
checking GitHub module core_trap.sh...OK
checking GitHub module info_distro.sh...OK
checking GitHub module info_game.sh...OK
checking GitHub module install_logs.sh...OK
[ OK ] Updating LinuxGSM gmodserver: Updating functions
[entrypoint.sh]update / installation done!
[prepareServer.sh]check configurations
[initConfig.sh]Request for replacing hostname to "(redacted)", source is found 1 times
[initConfig.sh]Request for replacing sv_password to "(redacted)", source is found 1 times
[initConfig.sh]Request for replacing sv_voiceenable to "0", source is found 1 times
[prepareServer.sh]force workshop download
[forceWorkshopDownload.sh]processing workshop collection 3036970017
[prepareServer.sh]install & mount gamefiles
./installAndMountAddons.sh: line 10: cd: /home/steam/.steam/steamcmd: No such file or directory
Heyho, probably the image just need to be rebuild I triggered it on docker hub, will take a bit.
Heyho, probably the image just need to be rebuild I triggered it on docker hub, will take a bit.
Just tried. Did not make a change. Same error. 😕
- It doesn't look like any linuxgsm.sh script is invoked without being steam / ttt user. Can you look inside and check who owns this file? It only makes sense if it's a shared volume or something like that.
- A quick fix doesn't help...; it makes the actual file user even more interesting.
Current testing shows the correct user on my side, at least.
Not that easy, because I don't have explicit control over the container startup and can enter it as long as it's running. Will try later.
When I ls -lsah /home/steam/log/script I get ls: cannot access '/home/steam/log/script': No such file or directory both before and after initialisation of the container.
What exactly is the reason that the docker images use multiple users?
Can you try to create that folder, maybe there is a lgsm issue and it couldn't find this folder during permission check and thats the actual isse.
Because Entrypoint is called with steam user ( I just called it ttt user too because it's named in your example ttt).
There is no call to linuxgsm.sh before the entrypoint, so it never has a root user or any other but steam during runtime.
That's why I asked if the volume is shared, but the message indicates a folder for your lgsm version is missing. So mkdir -p /home/steam/log/script should fix it, or a recent build with a current lgsm version as I used, probably.
Okay. I just wondered why there is so mod chown in the Dockerfile. Another thing that kind of irritates me is, that the volume is mounted to /home/steam/serverfiles (as described in the README), but the issue appears in /home/steam/log, which shouldn't even be in the volume. But I will try to create the folder anyways within the container later.
Also: Do you know which script should usually be responsible for creating /home/steam/log?
Creating the folder does not make a difference
Okay. I just wondered why there is so mod
chownin the Dockerfile. Another thing that kind of irritates me is, that the volume is mounted to/home/steam/serverfiles(as described in the README), but the issue appears in/home/steam/log, which shouldn't even be in the volume. But I will try to create the folder anyways within the container later.
- Up to this point every command in Dockerfile is executed as root.
- Yes the issued folder is not in the volume. So steam folder created with mkdir -p and afterwards rights are set
Also: Do you know which script should usually be responsible for creating /home/steam/log?
lgsm only
Creating the folder does not make a difference
hm... so probably root owns /home/steam/log but /home/steam is owned by steam user, else there would be more issues. How easy is it to create a local k8s to replicate it?
Edit: btw also looked into lgsm bug tracker but couldn't find an issue regarding that.
so probably root owns /home/steam/log but /home/steam is owned by steam user
Ran ls -lsah /home/steam:
also ran ls -lsah /home/steam/serverfiles
so for whatever reason, /home/steam is owned by root, even though server files is owned by steam. I guess that is the problem, as the not yet existing logs would then be owned by root as well. Will try to modify that and post again.
EDIT: as seen in the pictures, /home/steam/ is owned by steam, but /home/steam/serverfiles (so the mounted volume) is owned by root. Will try to modify that nevertheless.
Progress!
Couldn't modify the permissions on /home/steam/steamfiles/ within the container (missing permissions, as the steam user is not root), so I modified the permissions of the folder, which represents the volume on the hard drive. That seemed to solve the problem. But I'm not sure whether I can configure that in kubernetes.
Btw, regarding
How easy is it to create a local k8s to replicate it?
if you have docker desktop installed, you can just activate kubernetes in the settings. Linux installation can usually be done using package manager, k3s installs using install script.
I played around a bit with this tutorial. When I just use non-persistent volume, fsGroup works just fine and the root of the volume belongs to group 2000. However, when I use a persistent volume by using a persistent volume claim, the owner of the volume root is the owner of the folder on the host system. So, your container is just fine and I just need to figure out how to handle this correctly. Thanks for your effort ❤️🔥
Nice, good job!
Btw if you ran docker exec -it CONTAINER you can add -u root to have a different user if you need to.
Nice, good job!
Btw if you ran docker exec -it CONTAINER you can add -u root to have a different user if you need to.
Yeah thanks, but I want to refrain from using root within the running container. Will likely change something about the fs permission on the host (e.g. making the directory accessible to all users) or the volume provider.
Found a solution: For whatever reason, lgsm requires the parent folder of serverfiles not only to be writeable by steam-User, but also that the folder is owned by the steam-User. It seems like kubernetes volume providers aren't able to set the owner of volume folders at the moment. However, it is possible to alter the directory lgsm uses for the serverfiles by overwriting the according default variables. For completeness, a full kubernetes configuration for this image:
---
apiVersion: v1
kind: Namespace
metadata:
name: ttt
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: ttt
namespace: ttt
spec:
selector:
matchLabels:
app: ttt
template:
metadata:
labels:
app: ttt
spec:
securityContext:
fsGroup: 10000
runAsNonRoot: true
runAsUser: 10000
containers:
- name: docker-ttt
image: jusito/docker-ttt:gmod_ttt_debian
ports:
- containerPort: 27015
protocol: UDP
- containerPort: 27015
protocol: TCP
env:
- name: SERVER_PORT
value: "27015"
- name: WORKSHOP_COLLECTION_ID
value: "012345678"
- name: SERVER_NAME
value: "Feel free to choose a name"
- name: SERVER_PASSWORD
value: "NOYB"
# the following variables are required, because LGSM requires the server files folder to be owned by the 'steam' user
- name: "LGSM_SERVERFILES"
value: "/home/steam/serverfiles/lgsm"
- name: "SERVER_PATH"
value: "/home/steam/serverfiles/lgsm"
volumeMounts:
- mountPath: /home/steam/serverfiles
name: ttt-pv-storage
volumes:
- name: ttt-pv-storage
persistentVolumeClaim:
claimName: ttt-pv-claim
---
# Persistence Volume Claim to make the server boot faster (because the download and installation is fixed). Note that this assumes a local-path volume provider to be setup
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ttt-pv-claim
namespace: ttt
annotations:
volumeType: local
spec:
storageClassName: local-path
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 9Gi
# ---
## Service that can be used if you don't wanna use a separate load balancer
# apiVersion: v1
# kind: Service
# metadata:
# name: ttt
# namespace: ttt
# spec:
# type: LoadBalancer
# ports:
# - port: 27015
# targetPort: 27015
# protocol: UDP
# selector:
# app: tttOpened an issue at lgsm that it requires ownership, rather than read write access, see GameServerManagers/LinuxGSM#4323