Can't start - Permission denied

[voruti]

Describe the Bug
I just entered the command from the README.md (see below - only changed the path) and the container stops right away. (+ same when using the docker-compose.yml file)

Your Runtime Command or Docker Compose File
docker run -d --name=satisfactory-server -h satisfactory-server -v $(pwd)/config:/config -p 7777:7777/udp -p 15000:15000/udp -p 15777:15777/udp wolveix/satisfactory-server:latest

System Specs:

• OS: Debian GNU/Linux 10 (buster)

Additional Context
Log:

mkdir: cannot create directory '/config/backups': Permission denied,
mkdir: cannot create directory '/config/gamefiles': Permission denied,
mkdir: cannot create directory '/config/saves': Permission denied,
mkdir: cannot create directory '/config/gamefiles': Permission denied,
mkdir: cannot create directory '/config/gamefiles': Permission denied,
mkdir: cannot create directory '/config/gamefiles': Permission denied

[wolveix]

Hey! This is a duplicate of #43 I'm about to add additional information about this. You need to pass --user=1001 or whatever your user ID is on the host (run id).

[voruti]

Unfortunately this did not work (my id is 1000 and even with --user=1000 the error persists). Running with --user=0 works, though (yes, this is root).

So as root then:
It is able to create the directories, update (steamcmd I think?) and starts the download of Satisfactory:

Checking available space...,
Downloading the latest version of the game...,
Redirecting stderr to '/root/Steam/logs/stderr.txt',
/tmp/dumps is not owned by us - delete and recreate,
[  0%] Checking for available updates...,
[----] Downloading update (48 of 54,186 KB)...,
[  0%] Downloading update (3,658 of 54,186 KB)...,
[100%] Download complete.,
[----] Installing update...,
[----] Extracting package...,
[----] Extracting package...,
[----] Extracting package...,
[----] Extracting package...,
[----] Installing update...,
[----] Installing update...,
[----] Installing update...,
[----] Installing update...,
[----] Installing update...,
[----] Installing update...,
[----] Installing update...,
[----] Installing update...,
[----] Cleaning up...,
[----] Update complete, launching Steamcmd...,
Redirecting stderr to '/root/Steam/logs/stderr.txt',
[  0%] Checking for available updates...,
[----] Verifying installation...,
Steam Console Client (c) Valve Corporation,
-- type 'quit' to exit --,
Loading Steam API...OK,
,
Connecting anonymously to Steam Public...OK,
Waiting for client config...OK,
Waiting for user info...OK,
ERROR! Failed to install app '1690800' (Disk write failure)

Looks like another permission error??

[wolveix]

Hmm. Could you provide a little bit more information about your setup? You're running Debian 10, are you running as a non-root user? Are you writing to local storage? Any other information you think might be useful?

[voruti]

It's a VPS (this). The setup is as simple as it can be:

• Debian installation
• added a single user (id 1000) with access to sudo
• disabled login for root
• installed Docker

[wolveix]

Brilliant, thanks for the additional information. I'm familiar with Contabo, so there shouldn't be any unusual issues there. Just curious, does it work when you run the Docker command as root? So elevate to root via sudo -s or su -, then try running the command.

I know you passed root directly to Docker, but I'm just curious as to whether this changes anything.

[voruti]

No, everything as without root.

[wolveix]

Right, so could you try running it as root? :)

[voruti]

Right, so could you try running it as root? :)

Sorry. Yes, I did that. Nothing has changed. The same errors still show up.

[wolveix]

Hm, that doesn't make any sense. Are you able to run another Docker image successfully? Anything that would write to the host/mapped directory.

Also, try swapping out -v $(pwd)/config:/config with an absolute path.

[voruti]

Okay, found the problem. It was kind of my fault, but also kind of not:
When using Docker, I'm usually not creating the folders for the configuration files, etc.; Docker will create them automatically (owned by root) when starting the container.

I think you should implement something that checks the file/folder permission and fixes it automatically. Especially because the error also occurs if you start the image completely without volume mount (is this also the case for you?).

[wolveix]

Yeah, this is due to the fact that the image runs as steam which is not an elevated user. This is common and good practice as it prevents attacks that exploit images running everything as root. Unfortunately, this comes with the aforementioned caveat. I will add a check into the image that notifies the user. Sorry and thank you for your help!

[wolveix]

So this is interesting. Docker creates the config directory, but it creates it specifically as root, which is why the mkdir command fails in the container. Even if you run the Docker command with the --user flag specified, it still does it

[voruti]

In your Dockerfile: https://github.com/wolveix/satisfactory-server/blob/main/Dockerfile#L10 you are creating the /config folder. This is done as root user.
Adding a mkdir /config in line 9 is not possible, because

due to the fact that the image runs as steam

of insufficient rights.

[wolveix]

Right, but I'm not trying to add mkdir into the Dockerfile. This is not due to an issue with the Dockerfile per se, but rather how Docker functions under the hood. Everything in the Dockerfile runs as steam. But Docker creates the /config directory at runtime as root due to how Docker functions under the hood.

The reason many other images don't have this issue is due to the fact that the image itself runs as root, whereas this one runs as steam for security.

[wolveix]

The only way (that I can think of) to automatically fix this issue would be to run the image as root and then drop to steam in the init.sh script. But that defeats the whole security purpose outlined above, as the container itself would still be running as root. More than happy for feedback or criticisms :)

[voruti]

Adding RUN ls -lAh / to Dockerfile in line 9 and 12:

Step 5/10 : RUN ls -lAh /
 ---> Running in 6893d6130c87
total 68K
-rwxr-xr-x   1 root root    0 Oct 27 17:40 .dockerenv
drwxr-xr-x   1 root root 4.0K Mar  4  2021 bin
drwxr-xr-x   2 root root 4.0K Jan 30  2021 boot
drwxr-xr-x   5 root root  340 Oct 27 17:40 dev
drwxr-xr-x   1 root root 4.0K Oct 27 17:40 etc
drwxr-xr-x   1 root root 4.0K Mar  4  2021 home
drwxr-xr-x   1 root root 4.0K Mar  4  2021 lib
drwxr-xr-x   2 root root 4.0K Mar  4  2021 lib32
drwxr-xr-x   2 root root 4.0K Feb  8  2021 lib64
drwxr-xr-x   2 root root 4.0K Feb  8  2021 media
drwxr-xr-x   2 root root 4.0K Feb  8  2021 mnt
drwxr-xr-x   2 root root 4.0K Feb  8  2021 opt
dr-xr-xr-x 312 root root    0 Oct 27 17:40 proc
drwx------   2 root root 4.0K Feb  8  2021 root
drwxr-xr-x   3 root root 4.0K Feb  8  2021 run
drwxr-xr-x   2 root root 4.0K Feb  8  2021 sbin
drwxr-xr-x   2 root root 4.0K Feb  8  2021 srv
dr-xr-xr-x  13 root root    0 Oct 27 17:39 sys
drwxrwxrwt   1 root root 4.0K Mar  4  2021 tmp
drwxr-xr-x   1 root root 4.0K Mar  4  2021 usr
drwxr-xr-x   1 root root 4.0K Feb  8  2021 var
Removing intermediate container 6893d6130c87
 ---> 752dd1ef6e61
Step 6/10 : VOLUME /config
 ---> Running in dc9ab11e1ecd
Removing intermediate container dc9ab11e1ecd
 ---> 777c934cc6be
Step 7/10 : WORKDIR /config
 ---> Running in da5729f3fc15
Removing intermediate container da5729f3fc15
 ---> ccd0f7a460f4
Step 8/10 : RUN ls -lAh /
 ---> Running in 444ac7641722
total 72K
-rwxr-xr-x   1 root root    0 Oct 27 17:40 .dockerenv
drwxr-xr-x   1 root root 4.0K Mar  4  2021 bin
drwxr-xr-x   2 root root 4.0K Jan 30  2021 boot
drwxr-xr-x   2 root root 4.0K Oct 27 17:40 config
drwxr-xr-x   5 root root  340 Oct 27 17:40 dev
drwxr-xr-x   1 root root 4.0K Oct 27 17:40 etc
drwxr-xr-x   1 root root 4.0K Mar  4  2021 home
drwxr-xr-x   1 root root 4.0K Mar  4  2021 lib
drwxr-xr-x   2 root root 4.0K Mar  4  2021 lib32
drwxr-xr-x   2 root root 4.0K Feb  8  2021 lib64
drwxr-xr-x   2 root root 4.0K Feb  8  2021 media
drwxr-xr-x   2 root root 4.0K Feb  8  2021 mnt
drwxr-xr-x   2 root root 4.0K Feb  8  2021 opt
dr-xr-xr-x 315 root root    0 Oct 27 17:40 proc
drwx------   2 root root 4.0K Feb  8  2021 root
drwxr-xr-x   3 root root 4.0K Feb  8  2021 run
drwxr-xr-x   2 root root 4.0K Feb  8  2021 sbin
drwxr-xr-x   2 root root 4.0K Feb  8  2021 srv
dr-xr-xr-x  13 root root    0 Oct 27 17:39 sys
drwxrwxrwt   1 root root 4.0K Mar  4  2021 tmp
drwxr-xr-x   1 root root 4.0K Mar  4  2021 usr
drwxr-xr-x   1 root root 4.0K Feb  8  2021 var
Removing intermediate container 444ac7641722
 ---> 0361245327dc

---

But Docker creates the /config directory at runtime as root due to how Docker functions under the hood.

Yes it does this on the host, if you specify a volume mount.

But when starting the container without volume (eg. docker run --network host wolveix/satisfactory-server) the /config folder is used as it is and the container crashes.

[wolveix]

Really appreciate the insight @voruti! What would you suggest to resolve the issue? I'm not sure if it's possible without elevating the Dockerfile

[voruti]

Right, but I'm not trying to add mkdir into the Dockerfile.

There are two problems here:

Running with a volume mounted to the host system

The only way (that I can think of) to automatically fix this issue would be to run the image as root and then drop to steam in the init.sh script. But that defeats the whole security purpose outlined above, as the container itself would still be running as root.

I agree on that and came to the same conclusion.
I think it's best to let this as it is: More security but the user has to set correct permissions for the config folder on the host.

Running without a volume mounted to the host system

This is currently not possible. As early as in the Dockerfile the permissions are set incorrectly.

What would you suggest to resolve the issue?

You could move the /config folder to a place where the steam user has write access and then manually create the directory: eg. add to Dockerfile in line 9: RUN mkdir /home/steam/config (+ adjusting all paths to the new location):

Step 5/10 : RUN mkdir /home/steam/config
 ---> Running in 823c1f053f19
Removing intermediate container 823c1f053f19
 ---> bc3373959702
Step 6/10 : VOLUME /home/steam/config
 ---> Running in df836a77d6d1
Removing intermediate container df836a77d6d1
 ---> 4c6fd514d915
Step 7/10 : WORKDIR /home/steam/config
 ---> Running in 5d24b6fa0048
Removing intermediate container 5d24b6fa0048
 ---> 8c14352b6211
Step 8/10 : RUN ls -lah ..
 ---> Running in 2b3e76af8662
total 52K
drwxr-xr-x 1 steam steam 4.0K Oct 27 18:32 .
drwxr-xr-x 1 root  root  4.0K Mar  4  2021 ..
-rw-r--r-- 1 steam steam  220 Apr 18  2019 .bash_logout
-rw-r--r-- 1 steam steam 3.5K Apr 18  2019 .bashrc
-rw-r--r-- 1 steam steam  807 Apr 18  2019 .profile
drwxr-xr-x 3 steam steam 4.0K Mar  4  2021 .steam
-rw-r--r-- 1 root  root   640 Oct 27 15:51 Engine.ini
-rw-r--r-- 1 root  root   166 Oct 27 15:51 Game.ini
-rw-r--r-- 1 root  root   105 Oct 27 15:51 Scalability.ini
drwxr-xr-x 6 steam steam 4.0K Mar  4  2021 Steam
drwxr-xr-x 2 steam steam 4.0K Oct 27 18:32 config
-rwxr-xr-x 1 root  root  2.0K Oct 27 18:19 init.sh
drwxr-xr-x 7 steam steam 4.0K Oct 27 18:32 steamcmd
Removing intermediate container 2b3e76af8662
 ---> 6fa458bf0f6d

(Tested; server starts successfully)

[jb-dijkstra]

I'm experiencing this problem as well. Apart from the potential fix, is there anything I can do to run the container right now?

[wolveix]

@jb-dijkstra before starting the container, manually make the config directory that you map to the container. That fixes the issue. Make sure to delete any directory that may already be there, as it would have been created by Docker.

[jb-dijkstra]

That doesn't work for me. I'll try and give as much information as possible.

This is my docker-compose file:

This is my folder structure:

When I run docker-compose this happens:

This goes on for a while and the container keeps restarting.

The same happens when I try and use a Docker volume or run as another user. I can run Docker as root or as my own user "jelke".

[wolveix]

Did you try deleting and re-creating /home/jelke/satisfactory/config?

Stop the container, run rm -rf /home/jelke/satisfactory/config && mkdir /home/jelke/satisfactory/config, then start the container.

[wolveix]

Okay, permissions are now fixed for Docker volumes. This fix does not fix bind mounts just yet, but I'm working on it.

[Leopoldpaul]

Awesome to see you updating this docker project so quickly these days Wolveix! I had the same issue as the guys above. At first I was thinking there was an issue with Docker on Synology (There was a bug with being unable to run the container as root) But even after the workaround of toggling the root option the problem persisted. I checked what the issue was by adding "id" to the init.sh file and saw that the script was being run as uid 1000. My first instinct was changing the folder owner to the "steam" user I had already created months ago but I think that has a different UID. CHOWNing the folder fixed it for me too. Thanks!!

How did you make it With the Steam user ?

[wolveix]

@Leopoldpaul if you're still having permissions issues, you could try using a volume mount rather than a bind mount :) I know it's not ideal, but at least you'd be able to use the server!

[Leopoldpaul]

how can i make a volume mount

[wolveix]

Rather than specifying an absolute directory path, just write something like -v satisfactory-config:/config. Docker will automatically create the volume for you :)

[Leopoldpaul]

So instead of -v /volume1/Dateien/Leopold/Epic/SatisServer:/config
/volume1/Dateien/Leopold/Epic/satisfactory-config :/config

[wolveix]

No, you'd use -v satisfactory-config:/config

[Leopoldpaul]

the problem is i have to go in the volume1/Dateien because everything else is locked

[wolveix]

Have you tried what I suggested?

[andrewgdunn]

Anecdotally It looks like the container would not like to be run as root, but if you're doing deployments with podman it's actually better for the container to internally operate as root so that the UID shifting is nicely mitigated by podman. When you run as non-root, you will be exposed to the UID shifts.

I'd be in favor of an option to have the container think its running as root. Would simplify interaction with podman.

[Leopoldpaul]

Have you tried what I suggested?

wow dammm it works
but do i have the same functions with the save files as the original command

[Leopoldpaul]

where can i finde the save file directory?

[wolveix]

Firstly, make sure that the Satisfactory container is stopped. If you have a save file in your local directory called savefile.sav, you could copy it into the volume like so:

docker run -d --rm --name dummy -v satisfactory-config:/root alpine tail -f /dev/null
docker cp savefile.sav dummy:/root/savefile.sav
docker stop dummy

[Leopoldpaul]

Is there a way to double check the copie of the file because the game doesnt recognize the save file

[wolveix]

Did you follow the guide to load a save file here? https://github.com/wolveix/satisfactory-server#loading-your-save

[Leopoldpaul]

yeah

[wolveix]

Okay, so you'll probably want to exec into the container and check the directory. Do this:

docker exec -it satisfactory-server ls -lah /config/saves

[Katorone]

On my installation, it's the /home/steam directory that's having a permission issue.

mkdir: cannot create directory '/home/steam/.config': Permission denied
mkdir: cannot create directory '/home/steam/.config': Permission denied
mkdir: cannot create directory '/home/steam/.config': Permission denied
mkdir: cannot create directory '/home/steam/.config': Permission denied

Exposing /home to my filesystem shows that /home/steam is created as root.

Could you try if something like this solves this issue?

su -c "mkdir -p /config/{backups,gamefiles,saves}" steam || exit 1
su -c "mkdir -p "${GAMECONFIGDIR}/{Config/LinuxServer,Logs,SaveGames/server,server}"" steam || exit 1

I also wonder about FROM cm2network/steamcmd:root. You're trying to run steamcmd as 'steam', but why not use FROM cm2network/steamcmd:latest, which uses/provides the steam user? I'm new to docker, so I don't know if there's a good reason for this.

[fryfrog]

I'm experiencing this issue when using docker run --user uid:gid which results in mkdir: cannot create directory '/home/steam/.config': Permission denied because obviously something like /home is not going to allow the steam user inside to make folders.

Most Docker images deal w/ this by running as root at initialization, then running the actual programs as the UID/GID specified. They use env vars like -e PUID=1000 and -e PGID=1000.

[wolveix]

@Katorone the su commands won't work as we're running as steam which is not a privileged user for security reasons.

We're using the root image to sort out permissions issues (which fixes permissions for volumes), and then drop to steam before the end of the Dockerfile. The root image is the same as latest, except it starts as root to allow you to make any privileged changes.

[wolveix]

I'm experiencing this issue when using docker run --user uid:gid which results in mkdir: cannot create directory '/home/steam/.config': Permission denied because obviously something like /home is not going to allow the steam user inside to make folders.

Most Docker images deal w/ this by running as root at initialization, then running the actual programs as the UID/GID specified. They use env vars like -e PUID=1000 and -e PGID=1000.

Thanks for taking the time to write this out, but please read through this issue. These have already been talked about.

You shouldn't be having /home/steam/.config issues though. What does your Docker run command (or Compose file) look like? The steam user would absolutely and obviously have write access to its own home directory...what do you mean?

[Leopoldpaul]

Okay, so you'll probably want to exec into the container and check the directory. Do this:

docker exec -it satisfactory-server ls -lah /config/saves

Okay i got a Workaround for my Problems with running the Server on my Synology NAS.
First i have to start the Docker container in the DSM Docker app with High Privileges
Then i have to Set the right Port numbers and set a Volume bind into the /docker dir which is created from the Docker app beacuse in this dir Docker is the owner but i have also to set the folder to allow everyone to write (Im test some things to get rid of this potetial security problem).
After this everything works perfect.

[wolveix]

Ultimately, while it's frustrating, I believe it'll be much less of a headache to just run the container as root. I've already made the changes, and they've been pushed to the :dev image. I'll be pushing the commit shortly.

[wolveix]

This issue should now be resolved.

[msladek]

@wolveix I'm running this container in rootless mode without issues. Perhaps it's worth mentioning in the readme under "Known Issues".

[wolveix]

As is mentioned elsewhere (within one of the permissions issues), it's largely based on your setup and environment. The existing version of the project works in both environments, the previous version did not.