Can't start - Permission denied
voruti opened this issue · comments
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
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).
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??
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?
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
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.
No, everything as without root.
Right, so could you try running it as root? :)
Right, so could you try running it as
root? :)
Sorry. Yes, I did that. Nothing has changed. The same errors still show up.
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.
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?).
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!
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
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.
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.
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 :)
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
/configdirectory at runtime asrootdue 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.
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
Right, but I'm not trying to add
mkdirinto 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
rootand then drop tosteamin theinit.shscript. But that defeats the whole security purpose outlined above, as the container itself would still be running asroot.
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)
I'm experiencing this problem as well. Apart from the potential fix, is there anything I can do to run the container right now?
@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.
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".
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.
Yeah I did that multiple times:
When I run it with a docker volumes like in this config:
The same problem occurs:
Would it perhaps help if I move everything out of my users home folder and run it then?
Yeah, Docker volumes don't work right now. I think I'm just going to rebase the image to use root as the default user, then change user when running the game.
The directory being within your user's directory shouldn't matter. Though do make sure that you're passing the user: 1000 (find your user ID by running id) to your Docker Compose file.
I did a quick test in the mean time. There is indeed no change when moving out of the userfolder. Thanks for the (ultra) quick replies.
Do chown 1000.1000 config/.
@voruti that did the trick... it starts now. I also added the user to docker-compose file.
I have a similar problem. First the docker refused to install the Steam App with the same Errorcode mentioned above. Then I set the Permissions for the Folder that everyone can write. Worked. App installed successfully but then the Docker stops with the Error : Refusing to run with the root privileges. Is there a Fix for this Error
@jb-dijkstra I'm glad it's now working! @voruti thanks for the help there.
@Leopoldpaul please provide your full log as well as your Docker command or Compose file
@jb-dijkstra I'm glad it's now working! @voruti thanks for the help there.
@Leopoldpaul please provide your full log as well as your Docker command or Compose file
My Docker Command :
docker run -d --name=satisfactory-server -h satisfactory-server -v /volume1/Dateien/Leopold/Epic/SatisServer:/config -p 7777:7777/udp -p 15000:15000/udp -p 15777:15777/udp --user=0 wolveix/satisfactory-server:latest
It's because you're supplying --user=0. The server itself won't let you run it as root
Don't run with --user=0; just leave this out or use --user=1000 instead. Additionally ensure this: #44 (comment)
Okay without user it outputs Permission denied and with user=1000 it say Operation not permitted.
And I have to say Im not soo good in this docker stuff and im running on an Synology NAS which means that not all is working like normal Linux
--user=1000 depends on what your user ID is. Find this by running id as it may not be 1000.
Try totally removing the currently mapped directory, then create it as the user that will be running the container.
--user=1000depends on what your user ID is. Find this by runningidas it may not be1000.Try totally removing the currently mapped directory, then create it as the user that will be running the container.
id give me this:
Ah so you're running the container as root? In that case, don't supply the --user flag at all. I'll try a few things with running the container as root myself.
Ah so you're running the container as
root? In that case, don't supply the--userflag at all. I'll try a few things with running the container asrootmyself.
Without user i get the familiar Permission denied
You are running as root, but that's fine. Just ensure chown -R 1000.1000 /volume1/Dateien/Leopold/Epic/SatisServer.
You are running as root, but that's fine. Just ensure
chown -R 1000.1000 /volume1/Dateien/Leopold/Epic/SatisServer.
I deleted the dir SatisServer and made it new and after everything reinstalled and i got the same root error I tried your command but it didnt work. I think its due to that the User with the id 1000 doesnt exist on my NAS.
My NAS say when i check the SatisServer dir that this User doesnt exist when i try to cloes the Directory config window
I changed the Comand from 1000.1000 to Leopold.users because other dir have the same but the docker tells me the same Refusing to run with the root privileges.
Okay I tested more things and i have to run the docker command with user=0. All other id's have no permissions and the docker stops instantly. Chown commands doesnt change anything.
Thanks for your troubleshooting @Leopoldpaul! I'm going to rebase the image shortly which will fix the issue.
I have to Thank you guys for being so nice and your ambition to help me.
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!!
I'm having the same issue with permission errors but manually chown'ing the mounted volume isnt helping.
satisfactory-server:
image: 'wolveix/satisfactory-server:latest'
container_name: 'satisfactory'
hostname: 'satisfactory-server'
restart: unless-stopped
ports:
- '7777:7777/udp'
- '15000:15000/udp'
- '15777:15777/udp'
user: '1002'
volumes:
- $USERDIR/satisfactory:/config
environment:
- STEAMBETA=true`
shawn@citadel:~/ > \ls -l /opt | grep satis
drwxr-xr-x 6 satisfactory satisfactory 4096 Oct 28 18:20 satisfactory
shawn@citadel:~/ > id satisfactory
uid=1002(satisfactory) gid=1002(satisfactory) groups=1002(satisfactory)
It's able to create some of the folders inside the config folder but can't seem to create /home/steam/.config
shawn@citadel:~/ > \ls -l /opt/satisfactory/
total 12
drwxr-xr-x 2 satisfactory satisfactory 4096 Oct 28 18:19 backups
drwxr-xr-x 3 satisfactory satisfactory 4096 Oct 28 18:19 gamefiles
drwxr-xr-x 2 satisfactory satisfactory 4096 Oct 28 18:19 saves
shawn@citadel:~/ > docker logs -f satisfactory
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
Maybe building the container up on a linuxserver.io base image could help they implemented something (s6 overlay) that runs every container with a given user and group.
@NemesisRE yeah I have considered it. I'll hopefully have time to get to it tomorrow, but PRs are always welcome :)
Okay, permissions are now fixed for Docker volumes. This fix does not fix bind mounts just yet, but I'm working on it.
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 ?
@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!
how can i make a volume mount
Rather than specifying an absolute directory path, just write something like -v satisfactory-config:/config. Docker will automatically create the volume for you :)
So instead of -v /volume1/Dateien/Leopold/Epic/SatisServer:/config
/volume1/Dateien/Leopold/Epic/satisfactory-config :/config
No, you'd use -v satisfactory-config:/config
the problem is i have to go in the volume1/Dateien because everything else is locked
Have you tried what I suggested?
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.
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
where can i finde the save file directory?
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 dummyIs there a way to double check the copie of the file because the game doesnt recognize the save file
Did you follow the guide to load a save file here? https://github.com/wolveix/satisfactory-server#loading-your-save
yeah
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
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.
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.
@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.
I'm experiencing this issue when using
docker run --user uid:gidwhich results inmkdir: cannot create directory '/home/steam/.config': Permission deniedbecause obviously something like/homeis not going to allow thesteamuser inside to make folders.Most Docker images deal w/ this by running as
rootat initialization, then running the actual programs as the UID/GID specified. They use env vars like-e PUID=1000and-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?
Okay, so you'll probably want to
execinto 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.
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.
This issue should now be resolved.
@wolveix I'm running this container in rootless mode without issues. Perhaps it's worth mentioning in the readme under "Known Issues".
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.