Installing an ARK server on Linux

This builds an ARK: Survival Evolved dedicated server from nothing on a 64-bit Linux VPS: SteamCMD, a non-root user to own it, the launch string with its map and ports, and a systemd unit that survives a reboot and stops the server cleanly. Commands are for Debian 12 and Ubuntu 22.04 or newer, with the RHEL family equivalents where they differ.

You need root or sudo and a way in. See Connecting to your server if you do not have an SSH session yet. Read Running an ARK server first if you have not sized the machine, because ARK is the one game server people routinely try to run on hardware that cannot hold it.

Install it

1. Install what SteamCMD needs

   SteamCMD is a 32-bit program, so a 64-bit host needs the 32-bit C and C++ runtimes even though the ARK server itself is 64-bit.

   On Debian and Ubuntu:

   ShellCopy

   sudo dpkg --add-architecture i386
   sudo apt update
   sudo apt install -y curl tar ca-certificates lib32gcc-s1 lib32stdc++6

   On RHEL, AlmaLinux, and Rocky:

   ShellCopy

   sudo dnf install -y curl tar glibc.i686 libstdc++.i686

   On Ubuntu 18.04 and older the package is named lib32gcc1 rather than lib32gcc-s1.

2. Create a user for the server

   ARK does not need root and should not have it. It is a large closed-source binary listening to the internet, and it loads third-party mod code into its own process.

   ShellCopy

   sudo useradd -m -d /home/ark -s /bin/bash ark

   Everything below happens inside /home/ark. If you plan to run a cluster, run every map as this one user, because they all need write access to the same transfer directory.

3. Install SteamCMD

   Switch to the ark user and unpack it into its own directory:

   ShellCopy

   sudo -u ark -i
   mkdir -p ~/steamcmd && cd ~/steamcmd
   curl -sSL https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz | tar zx

   If that download fails, the current URL is on Valve's SteamCMD page. Run it once on its own so it can self-update before you ask it to do any work:

   ShellCopy

   ~/steamcmd/steamcmd.sh +quit

4. Download the server files

   The ARK dedicated server is Steam app 376030. You do not need to own the game, so an anonymous login is enough:

   ShellCopy

   ~/steamcmd/steamcmd.sh \
     +force_install_dir /home/ark/server \
     +login anonymous \
     +app_update 376030 validate \
     +quit

   This pulls down tens of gigabytes and will take a while. If it stops partway, run exactly the same command again: validate makes SteamCMD resume and repair what is already there rather than start from the beginning. The same command is how you update the server later.

5. Start it once by hand

   The binary lives in ShooterGame/Binaries/Linux. Run it in the foreground the first time so you can watch what it does:

   ShellCopy

   cd /home/ark/server/ShooterGame/Binaries/Linux
   ./ShooterGameServer "TheIsland?listen?SessionName=My ARK Server?Port=7777?QueryPort=27015?MaxPlayers=20?ServerAdminPassword=CHANGE_THIS" -server -log

   Everything before the space is one single argument, which is why it is quoted: the session name contains spaces and the shell would otherwise split it. Change ServerAdminPassword to something of your own before you run this, not after.

   This first start is slow. The next section explains how to tell it apart from a start that has hung.

What the launch string means

The map name comes first, then a chain of options separated by ?, then command-line flags starting with - after the closing quote.

Cluster options go here as well. See Running an ARK server for what -clusterid= and -ClusterDirOverride= do.

The first start takes a long time

The first start does three slow things one after another: it downloads and unpacks any mods, it loads the map into memory, and it generates the save and the configuration files that do not exist yet. For most of that there is no output at all, so an ARK server that is working correctly looks identical to one that has frozen.

Two ways to tell them apart. Resident memory climbing means the world is still loading:

ps -o pid,rss,etime,args -C ShooterGameServer

And the log file growing means it is still doing something:

tail -f /home/ark/server/ShooterGame/Saved/Logs/ShooterGame.log

ARK binds its ports only once loading has finished, so the definitive sign that the server is up is the sockets appearing:

sudo ss -lunp | grep ShooterGame

Until that returns something, nothing can reach the server and there is no point looking at your firewall. Once it does, and players still cannot get in, the problem is between the machine and the player: check your rules under Port rules.

Configuration files appear after the first run

Once the server has started and stopped once, you have:

/home/ark/server/ShooterGame/Saved/Config/LinuxServer/GameUserSettings.ini
/home/ark/server/ShooterGame/Saved/Config/LinuxServer/Game.ini

GameUserSettings.ini holds most of what people want to change: rates, taming speed, the autosave interval in AutoSavePeriodMinutes, RCON, and the ActiveMods list. Game.ini holds the more detailed multipliers, and on some builds it is not created for you, in which case make it yourself in the same directory.

Run it under systemd

Write /etc/systemd/system/ark.service:

[Unit]
Description=ARK Survival Evolved dedicated server
After=network-online.target
Wants=network-online.target
 
[Service]
Type=simple
User=ark
Group=ark
WorkingDirectory=/home/ark/server/ShooterGame/Binaries/Linux
ExecStart=/home/ark/server/ShooterGame/Binaries/Linux/ShooterGameServer "TheIsland?listen?SessionName=My ARK Server?Port=7777?QueryPort=27015?MaxPlayers=20?ServerAdminPassword=CHANGE_THIS" -server -log
LimitNOFILE=100000
Restart=on-failure
RestartSec=30
TimeoutStopSec=300
 
[Install]
WantedBy=multi-user.target

Then:

sudo systemctl daemon-reload
sudo systemctl enable --now ark
sudo journalctl -u ark -f

Three lines in that unit are doing real work.

LimitNOFILE=100000 raises the number of files and sockets the process may have open. ARK wants far more than a default shell session is given, and when it runs out the failures are strange and unspecific rather than a clear error, so this is worth setting before you need it.

TimeoutStopSec=300 is the important one. When you stop a service, systemd sends a polite signal and then, by default, kills the process outright 90 seconds later. An ARK server writing a large world save can still be writing at 90 seconds, and a kill landing in the middle of that write is one of the two common ways an ARK save is destroyed. Time how long your own save takes and leave generous room above it.

Restart=on-failure brings the server back if it crashes, without fighting you when you stop it deliberately.

Updating

ARK clients and servers have to match: when the game updates, players cannot join your server until you update it too. You can put the SteamCMD line in ExecStartPre so every restart updates first, at the cost of making every restart slow and unpredictable in length. The alternative is to update deliberately:

sudo systemctl stop ark
sudo -u ark /home/ark/steamcmd/steamcmd.sh \
  +force_install_dir /home/ark/server \
  +login anonymous \
  +app_update 376030 validate \
  +quit
sudo systemctl start ark

Saving and stopping cleanly

Saves are destroyed in two ways, and both are avoidable.

Something kills the process during a write. That means kill -9, systemd reaching its stop timeout, the kernel's out-of-memory killer when the machine runs out of RAM, or the host losing power. The first two are yours to control: never use kill -9 on a game server, and set TimeoutStopSec high enough.

The disk fills up. A save that runs out of space partway through truncates the file, with the same result. Check df -h regularly, and remember that ARK keeps timestamped copies of previous saves, so the save directory grows on its own.

The safe way to stop the server is to tell the game to save and exit first, rather than signalling the process. ARK's RCON speaks the Source protocol, so any Source RCON client works, mcrcon and rcon-cli among them. Send SaveWorld, wait for it to come back, then send DoExit, then stop the unit:

sudo systemctl stop ark

Give it time. systemctl stop returning immediately does not mean the process has gone, and watching the journal while it stops is worth doing the first time so you know how long your server actually needs.

Rolling back to a working save

ARK keeps timestamped copies of the world alongside the live one. Stop the server first, then look at what is there:

sudo systemctl stop ark
cd /home/ark/server/ShooterGame/Saved/SavedArks
ls -lt

Pick the newest timestamped copy of your map's .ark file from that listing, put the broken one aside rather than deleting it, and put the copy in its place:

BACKUP=the-timestamped-file-you-chose.ark
mv TheIsland.ark TheIsland.ark.broken
cp "$BACKUP" TheIsland.ark
sudo systemctl start ark

The world file is not the whole story. The .arkprofile and .arktribe files in the same directory hold player characters and tribe membership, and restoring a world without the matching profiles gives you a map where nobody has a character. Restore the set together, which is the reason to back up the whole directory rather than a single file.

Backing it up yourself

Everything worth keeping is under ShooterGame/Saved, which is small next to the tens of gigabytes of installed game. Copy that directory off the machine on a schedule, and keep more than one generation, because a corrupt save is often noticed a day after it happened. See Backups for what the panel keeps for you, and treat your own copy as the one you actually plan to restore from.

Related