Kubernetes Helm filesystem permissions check and fsgroup

[Divinii]

The current deployment in Kubernetes does not work properly for me because of various reasons:

fsgroup is not set to 10000

When obtaining storage from Kubernetes while running a specific userid other than root you want to tell Kubernetes to handle the Permissions for you with fsgroup:

spec:
  template:
    spec:
      securityContext:
        fsGroup: 10000

Filesystem permission check only checks the folder permissions of the Persistent Mountpoint

In my case the Mountpoint is owned by root but I set fsgroup to 10000 which results in the Permissions in the Volume to be 10000 when you create files. I think the permissions check could be improved by checking if a file inside /home/steam/enshrouded/savegame/ can be created.

Success! App '2278520' fully installed.
INFO: Enshrouded server config not present, copying example

2024-01-25T20:39:05.480217832+01:00 ERROR: The ownership of /home/steam/enshrouded/savegame is not correct and the server will not be able to save...
2024-01-25T20:39:05.480221359+01:00 the directory that you are mounting into the container needs to be owned by 10000:10000
from your container host attempt the following command 'chown -R 10000:10000 /your/enshrouded/folder'
2024-01-25T20:39:05.480225326+01:00 

Set scaling and upgrade policy to recreate

When a Volume in Kubernetes is RWO (ReadWriteOnce) you cannot redeploy the workload because the pv cannot be attached to the newly created pod.

spec:
  strategy:
    type: Recreate

I hope this helps, if you need me to test anything on kubernetes for you hit me up!

[jsknnr]

Hey thanks for this! Admittedly I have not tested this on my own cluster since I made that change. I was just trying to help folks running outside of Kubernetes that think they need to have access to the files locally and keep doing bind mounts. I'll enhance the check and make your recommended change regarding the security context. Cheers.

Would not the recreate potentially cause a loss of data?

[Divinii]

Well the difference is that with the behavious as is it creates a second Pod on updates/redeploys, this pod tries to mount the PV and then fails if the PV is RWO. Recreate Terminates the Pod gracefully, after it is fully terminated it creates the new Pod. It does not cause a loss of data. I would be more concerned with a loss of data with the behaviour as is, because on a redeploy two servers try to access the same savegame at the same time. (depending on how fast the server process actually starts) In my case it took a few minutes to start the server fully.

[jsknnr]

Ok - that makes sense to me. I will make the necessary change.

[tchupp]

Using a StatefulSet might be a good alternative as well, since they are designed to handle the PVC and Recreation

[jsknnr]

That's actually not a bad idea, I didn't think about doing a stateful set. I'll play around with this.

[tchupp]

For the issue mentioned above with fs groups, I changed the entrypoint to have this:

    # Check for proper save permissions
    if ! touch "${ENSHROUDED_PATH}/savegame/test"; then
        echo ""
        echo "ERROR: The ownership of /home/steam/enshrouded/savegame is not correct and the server will not be able to save..."
        echo "The directory that you are mounting into the container needs to be owned by 'steam' (uid 10000)"
        echo "from your container host attempt the following command 'chown -R 10000:10000 /your/enshrouded/folder'"
        echo ""
        exit 1
    fi

    rm "${ENSHROUDED_PATH}/savegame/test"

[jsknnr]

This has been fixed in image v2.0.2