Open LvInSaNevL opened 5 months ago
My 2 cents to get the container running, using an exposed volume, like you (instead of letting docker handle the volume).
groupadd enshrouded -g 10000
useradd enshrouded -u 10000 -g 10000 -m -s /bin/bash
chown -R enshrouded:enshrouded /path/on/host/enshrouded
And then in the compose, the source needs to reflect this folder, obviously.
services:
enshrouded:
image: sknnr/enshrouded-dedicated-server:latest
ports:
- "15636:15636/udp"
- "15637:15637/udp"
environment:
- SERVER_NAME=TestEnshrouded
- SERVER_PASSWORD=testing
- GAME_PORT=15636
- QUERY_PORT=15637
- SERVER_SLOTS=16
- SERVER_IP=0.0.0.0
volumes:
- type: bind
source: /path/on/host/enshrouded
target: /home/steam/enshrouded/savegame
bind:
create_host_path: true
restart: unless-stopped
network_mode: bridge
@TrueOsiris Okay, do I need to make the enshrouded
user on the server?
Also, I just messed up my docker config when I was copying it over, that's my bad it should be this
ports:
- "15636:15636/udp"
- "15637:15637/udp"
I'll update it in my original question too.
The user doesn't need to be named 'enshrouded'. It can be anything. You need to create (or have) a user and group, both with id 10.000. Also, u need to make that user+group the owner of the exposed volume folder.
You ONLY need this because you use an exposed host volume (like me): ./save_data:/home/steam/enshrouded/savegame
I used an absolute path in the docker-compose.yaml: source: /path/on/host/enshrouded
U use a relative path, based on the folder you have your docker-compose.yml in: ./save_data
Both are exposed volumes.
The alternative is having docker manage the persistent volume, as the dev of this repo is doing.
services:
...
volumes:
- enshrouded-persistent-data:/home/steam/enshrouded/savegame
volumes:
enshrouded-persistent-data:
Then the volume is also persistent, but u can only reach it through docker commands. Docker then will handle rights and users, making this part easier. However, in most cases you do not want that, as you want to backup & restore files in those exposed volumes on an OS level.
The fact that the container access its volumes with user & group 10000 is embedded in the image and might even be embedded in the dedicated server software, imho.
Yes, in your original compose file, you have the volume being presented as a bind mount. When using the bind mount you need to make sure the directory is owned by 10000:10000. You do NOT need to create the user on the host. Simply chown -R 10000:10000 /your/mount/directory
. Also you should use an absolute path for the host portion of the directory, not a relative one.
The reason in all of my examples I have Docker/Podman create the volume is because the permissions will be correct for the container and you don't have to worry about it. For most people this will be fine. For folks with different storage setups they may choose to do a bind mount to utilize specific storage, that is fine. You just need to make sure the permissions are correct on the directory you are bind mounting, that the directory actually exists, and that you use an absolute path.
Setting a specific user and group ID is best practice. I choose 10000 as this is best practice for security and compatibility reasons as it lessens the chances of having a host collision with IDs that may already be in use on the host. The server software does not care. Though since I am running everything as the steam user inside of the container (with those IDs) the permissions do need to be correct because then the software won't be able to write to the volume.
Correction to @TrueOsiris you can still access the volume from the host with Docker/Podman managed volumes. You can find them by default at /var/lib/docker/volumes
with docker and with podman /home/$(whoami)/.local/share/containers/storage/volumes/
You do NOT need to create the user on the host. Simply chown -R 10000:10000 /your/mount/directory
I absolutely was unaware that this was possible. Seems good practice to create the user & group though.
You can find them by default at
/var/lib/docker/volumes
with docker and with podman/home/$(whoami)/.local/share/containers/storage/volumes/
Those foldernames have only the docker-compose tags as name (on my unraid system), making it rather hard to crawl through.
Anyway, I have one folder with all my docker-stacks in subfolders, with compose files & setups, which I push to github. Then another folder with all the volumes, with a similar structure. Makes it easy to go through with other apps, imho. But that's just flavor.
Yeah, all of that is fine. I just try to use path of least resistance in all of my examples for folks that may not be as experienced.
The user doesn't need to be named 'enshrouded'. It can be anything. You need to create (or have) a user and group, both with id 10.000. Also, u need to make that user+group the owner of the exposed volume folder.
You ONLY need this because you use an exposed host volume (like me): ./save_data:/home/steam/enshrouded/savegame I used an absolute path in the docker-compose.yaml:
source: /path/on/host/enshrouded
U use a relative path, based on the folder you have your docker-compose.yml in:./save_data
Both are exposed volumes.The alternative is having docker manage the persistent volume, as the dev of this repo is doing.
services: ... volumes: - enshrouded-persistent-data:/home/steam/enshrouded/savegame volumes: enshrouded-persistent-data:
Then the volume is also persistent, but u can only reach it through docker commands. Docker then will handle rights and users, making this part easier. However, in most cases you do not want that, as you want to backup & restore files in those exposed volumes on an OS level.
The fact that the container access its volumes with user & group 10000 is embedded in the image and might even be embedded in the dedicated server software, imho.
Okay so I followed the instructions in this comment from @TrueOsiris and updated my docker-compose to reflect it but I am still not able to get this to run. I think it might still be related to file permissions but I am not sure.
If I just start the server without any data the server starts fine and runs without crashing but it still doesn't write anything to the host computer. But if I pre-seed the server with another save folder it will write to the log files.
In `enshrouded_server.log I am getting a bunch of errors that look like this
File command of type '12' failed with error 'file not found'.
Then it will continue and start the server like normal (I think? According to the logs) but I am unable to connect to it from another computer.
groupadd enshrouded -g 10000 useradd enshrouded -u 10000 -g 10000 -m -s /bin/bash chown -R enshrouded:enshrouded /path/on/host/enshrouded
What does path/on/host mean, is it in the Docker container or locally?
Well /path/on/source
is just a fake file path, but that is the path the save file on the actual local server.
But we ended up just starting a new server because we weren't that far into it. It has been working for us fine for a few weeks now though, including through restarts!
Hey guys I am trying to set up a dedicated server on my Linux (running Ubuntu 22.04) host but the docker container wont stay up for more than ~1 minute before shutting down. I don't see any logs and it doesn't actually save any files to my directory.
Here is my
docker-compose.yaml
I changed the sever IP from the
0.0.0.0
that was in the README to127.0.0.1
based on the advice from this issueI also noticed that when I got connected to the server
enshrouded_server_example.json
was not updated with my information so I manually updated that and restarted the container but no luck there either.Maybe I am missing something with the
docker-compose
?Edit: I messed up my port config so I corrected that