jsknnr / enshrouded-server

Run Enshrouded dedicated server in a container
MIT License
176 stars 20 forks source link

Server crashing on Ubuntu 22.04 LTS #50

Open LvInSaNevL opened 5 months ago

LvInSaNevL commented 5 months ago

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

services:
  enshrouded:
    image: sknnr/enshrouded-dedicated-server
    container_name: enshrouded
    ports:
      - "15636:15636/udp"
      - "15637:15637/udp"
    environment:
      - SERVER_NAME: "My Server"
      - SERVER_PASSWORD: "MyPassword"
      - GAME_PORT: 15636
      - QUERY_PORT: 15637
      - SERVER_SLOTS: 4
      - SERVER_IP: 127.0.0.1
    volumes:
      - ./save_data:/home/steam/enshrouded/savegame

I changed the sever IP from the 0.0.0.0 that was in the README to 127.0.0.1 based on the advice from this issue

I 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

TrueOsiris commented 5 months ago

My 2 cents to get the container running, using an exposed volume, like you (instead of letting docker handle the volume).

LvInSaNevL commented 5 months ago

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

TrueOsiris commented 5 months ago

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.

jsknnr commented 5 months ago

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/

TrueOsiris commented 5 months ago

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.

jsknnr commented 5 months ago

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.

LvInSaNevL commented 5 months ago

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.

bonsaibauer commented 4 months ago

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?

LvInSaNevL commented 4 months ago

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!