Permission issues about docker-ttt HOT 18 CLOSED

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: ttt

from docker-ttt.

Heyho, probably the image just need to be rebuild I triggered it on docker hub, will take a bit.

from docker-ttt.

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. 😕

from docker-ttt.

1. 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.
2. 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.

from docker-ttt.

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.

from docker-ttt.

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?

from docker-ttt.

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.

from docker-ttt.

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.

from docker-ttt.

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.

from docker-ttt.

Also: Do you know which script should usually be responsible for creating /home/steam/log?

from docker-ttt.

Creating the folder does not make a difference

from docker-ttt.

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.

1. Up to this point every command in Dockerfile is executed as root.
2. 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.

from docker-ttt.

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.

from docker-ttt.

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.

from docker-ttt.

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 ❤️‍🔥

from docker-ttt.

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.

from docker-ttt.

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.

from docker-ttt.

Opened an issue at lgsm that it requires ownership, rather than read write access, see GameServerManagers/LinuxGSM#4323

from docker-ttt.