When a Valheim dedicated server dies during start-up, the cause is nearly always one of six things: the Steam library steamclient.so cannot be found (Linux only), the password breaks one of the game's rules, the world file is damaged, another process already holds the port, BepInEx fails before the game loads, or the process runs out of memory while loading a large world. Each leaves a different trace in the log, and the log is where every fix starts. Read it from the top, not the bottom - the last lines of a crashed server are usually the shutdown, and the reason is twenty lines above them.
This post goes through each failure, what it looks like and how to fix it, plus how to tell a server that crashes once from one stuck in a restart loop. It assumes the server was installed with SteamCMD or a hosting panel; if you are still installing, the SteamCMD Linux install guide covers a clean setup that avoids most of these.
Read the log first#
A Valheim server writes to standard output unless -logFile is set. Where to look:
| How it runs | Where the log is |
|---|---|
| Panel (Pterodactyl and similar) | The console tab, live; earlier output in the server's log view |
| Linux, by hand | The terminal, or the file given to -logFile |
| Linux, systemd service | journalctl -u valheim -n 300 (your unit name) |
| Windows | The console window, or the -logFile path |
| With BepInEx | Also BepInEx/LogOutput.log in the server folder |
If the console window closes before you can read it, add -logFile with a path so the output survives the crash. Then read from the first line. A healthy start goes roughly in this order: Unity initialises, Steam's game server API loads, the world loads or is generated, the server registers, and on a crossplay server a line with the join code appears. Wherever that sequence stops is where the problem is.
A useful habit: copy the log out before you restart anything. On many setups the next start overwrites it, and with it the only evidence. Game server logs explained covers how to read start-up logs in general and what to keep.
Linux: steamclient.so and missing libraries#
The most common start-up failure on a self-installed Linux server is the Steam API failing to initialise. The log contains lines along these lines:
dlopen failed trying to load:/home/steam/.steam/sdk64/steamclient.sowith error:/home/steam/.steam/sdk64/steamclient.so: cannot open shared object file[S_API] SteamAPI_Init(): Sys_LoadModule failed to load: ...The exact wording varies by version, and some of these lines are harmless: the loader tries several paths, and a failure on one is fine if a later line says the library loaded. What matters is whether the server goes on to start. If it stops, the server cannot find a usable steamclient.so.
The server ships its own copy in linux64/, and the stock start_server.sh points the loader at it before launching. The important lines in that script are:
export templdpath=$LD_LIBRARY_PATHexport LD_LIBRARY_PATH=./linux64:$LD_LIBRARY_PATHexport SteamAppId=892970./valheim_server.x86_64 -nographics -batchmode -name "Longship Crew" \ -port 2456 -world "Midgard" -password "herring-barrel-42" -public 1export LD_LIBRARY_PATH=$templdpathThings that break it:
- Running the binary directly. Calling
./valheim_server.x86_64from a systemd unit or your own script without settingLD_LIBRARY_PATHskips the fix. Either runstart_server.sh, or set the same variables in your unit withEnvironment=. - Relative paths from the wrong directory.
./linux64is relative. A service that does not set its working directory to the server folder looks in the wrong place. SetWorkingDirectory=in the unit. - `SteamAppId` missing.
892970is the game's app ID (the server's install ID is896660). Without it the Steam API may not initialise for the right app. - The sdk64 copy. A common extra step is to create
~/.steam/sdk64/for the user running the server and copylinux64/steamclient.sointo it. It does no harm and fixes setups where the loader insists on that path.
Missing system libraries cause similar early stops. On Debian and Ubuntu, a minimal image may lack libraries the Unity runtime expects. libatomic1 and the PulseAudio client library are the usual ones; install them with the package manager and try again. The log line names the missing .so; search your distribution's packages for that file name rather than guessing.
Password and name rules#
Valheim refuses to start a server whose password breaks its rules, and it does so in a single line that scrolls past instantly. The rules:
- At least five characters.
- The password must not appear in the server name.
- The password must not appear in the world name.
A server called Bjorn's Hall with the password bjorn stops at once. So does world Asgard with password asgard1. Pick a password that shares no word with either. If you want to run with no password at all - a server hidden with -public 0 on a trusted network, for instance - test it on your version rather than assuming; the behaviour of empty passwords has differed between versions and setups, and a long password costs you nothing.
Quoting matters too. A name with spaces needs quotes on the command line, and a password with characters your shell treats specially ($, !, backticks) needs single quotes on Linux. A broken quote does not always produce an error; it can silently make the rest of the line part of the name. Valheim launch arguments reference lists every argument and its rules.
World load errors#
If Steam initialises and the server stops while loading the world, the world file is the suspect. A Valheim world is two files in worlds_local: Name.fwl (name, seed, a few hundred bytes) and Name.db (everything else). Signs of a damaged world:
- An exception during world load -
EndOfStreamExceptionand similar - followed by the server exiting. - A
.dbfile that is zero bytes, or far smaller than yesterday's. - A
.fwlthat is zero bytes; the server cannot read the world's metadata at all.
These almost always follow an unclean stop during a save: the process was killed, the machine lost power, or the disk filled while the world was being written. The game keeps earlier copies to recover from: Name.db.old and Name.fwl.old from the previous save, and the automatic backups named like Name_backup_auto-20261011120000.db in the same folder.
Recovery, in order:
- Stop the server. Copy the whole
worlds_localfolder somewhere safe before touching anything. - Rename the damaged
Name.dbaside, then copyName.db.oldtoName.db. Do the same with the.fwlif it is the damaged one. - Start and check the log for the world loading.
- If that fails too, restore the newest automatic backup the same way, or a real backup from outside the server.
The rest of the subject - backup flags, what the automatic backups cover and do not, and how to restore properly - belongs to Valheim server backups and world corruption, so it is not repeated here.
The world name mismatch that looks like a reset
Not every world problem is a crash. If -world does not match the file name exactly - capitals included, without the extension - the server does not fail; it generates a fresh world under the new name, and players arrive on an empty map. The original files are still there. Fix the name and restart.
Port already in use#
Two Valheim servers cannot share a game port on the same address, and the second one to start fails or behaves strangely. Causes:
- A ghost process. The previous server did not exit, often after a terminal was closed or a service restarted badly. It still holds the port.
- Two servers, same `-port`. Several servers on one machine each need their own pair -
2456,2466,2476and so on, with the query port one above each. - Something else on the range. Rare, but other software can sit on UDP ports in this range.
On Linux, find what holds the port:
$ ss -ulpn | grep -E ':245[6-8]'$ pgrep -a valheim_serverIf an old valheim_server.x86_64 is still running, stop it cleanly - kill -INT <pid> asks it to save and exit - and only escalate to kill -9 if it does not go. On Windows, Task Manager or netstat -ano with findstr 2456 gives the process ID. Valheim ports 2456-2458 explained covers spacing several servers on one IP.
On a hosted panel this one rarely happens, because each server is its own container with its own allocated ports.
BepInEx and the preloader#
A modded server adds a stage that runs before the game itself. BepInEx's Doorstop injector loads first, the preloader patches the game, and only then do Valheim and the plugins start. A failure in that chain stops the server before any Valheim output appears, or crashes it a few seconds later with an exception that names a mod.
Where it goes wrong:
- The wrong start script. With BepInEx, the server must start from
start_server_bepinex.shon Linux. Starting fromstart_server.shruns vanilla - no crash, but no mods either, which leads to a different confusion. - The script will not run.
Permission deniedmeans it is not executable:chmod +x start_server_bepinex.sh.bad interpreter: /bin/bash^Mmeans it was saved with Windows line endings; convert it withdos2unixor re-extract the pack. - Missing pieces. The pack's
doorstop_libsfolder and, on Windows,winhttp.dllmust sit in the server root next to the binary. Unpacking into a subfolder is a classic mistake. - A mod built for another version. After a game patch, mods compiled against the old game can throw
MissingMethodExceptionorTypeLoadExceptionas they load. The exception names the plugin. - A mod missing its dependency. Most content mods need Jotunn or a similar library; BepInEx logs that a plugin was skipped because a dependency is missing.
BepInEx/LogOutput.log has the full trace. The fastest way to find a bad plugin is halving: move half of BepInEx/plugins out, start, and repeat on whichever half still fails. A patch day breaks mods across the board; what to do when a mod update breaks has the general routine, and the BepInEx install itself is in Valheim mods with BepInEx on a server.
Out-of-memory kills#
A big world needs its memory at load time: the server reads the whole .db into memory, and a long-lived world with large builds and terraforming can need several gigabytes before the first player arrives. If the limit is lower, the process is killed by the kernel - not by Valheim - and the log just stops, often in the middle of world loading, with no error from the game at all.
Signs on your own Linux machine:
$ dmesg -T | grep -i -E 'out of memory|killed process'$ journalctl -k | grep -i oomA line naming valheim_server is the answer. An exit code of 137 from a container or service manager means the same thing: killed with SIGKILL, almost always for memory. Linux swap and the OOM killer explains why the kernel picks the process it does.
Fixes, in the order to try them:
- Give it more memory. Sizing by group and world age is in how much RAM a Valheim server needs.
- Remove heavy mods to test. Content mods add prefabs and memory; a world that loads vanilla and dies modded has its answer.
- Check for runaway growth. If the
.dbhas grown suddenly, something in the world - item drops left by a farm, a mod spawning objects - may be the real problem.
On RE:NODE, a server that reaches its memory limit is stopped and restarted clean rather than left to swap, so you see a restart rather than a server crawling along. That also means an out-of-memory stop is a kill, not a save: whatever happened since the last save is lost, which is one more reason to keep -saveinterval short on a big world.
When it keeps restarting#
A single crash is a puzzle; a server crashing every time it starts is a loop, and a loop needs different handling. Every attempt rewrites the log, can overwrite the world's .old copy with something worse, and on a host may trigger protections. On RE:NODE the crash watcher checks every two minutes, and three unrequested restarts in an hour put a warning on the server page and open a ticket automatically; six suspend the server until it is looked at. Restarts you asked for do not count.
So when a server loops:
- Stop it. Do not let it keep trying.
- Copy the log and the
worlds_localfolder off the server. - Change one thing - remove plugins, restore the
.oldworld, raise memory - and start once.
Why your game server keeps restarting and game server crash loops cover the general method; the Valheim-specific causes are the ones above.
Other start-up failures#
A few rarer ones, briefly:
- Missing `-nographics -batchmode`. Without them, a headless Linux server can try to open a display and stop. Both belong on every dedicated start line.
- A half-finished update. An update interrupted mid-download leaves mismatched files. Run
steamcmd +force_install_dir <dir> +login anonymous +app_update 896660 validate +quitto repair it. - Permissions. A server folder copied as root and run as another user cannot write its world or log.
chown -Rthe folder to the user that runs the server. - `-savedir` pointing nowhere. A path that does not exist or is not writable stops saves, and on some setups start-up. Valheim savedir and file locations covers the defaults.
FAQ#
Why does my Valheim server close straight after starting with no error?
Usually because the error is there and scrolled past: the password rule is the classic. Start with -logFile set to a path and read the file from the top. If the log really is cut off mid-line, the process was killed from outside, most often for memory.
Is the steamclient.so error always fatal?
No. The loader tries several locations and logs a failure for each it cannot use. If a later line says the library loaded and the server continues to the world load, ignore it. It only matters when the server stops right after.
Can a mod stop the vanilla server from starting?
Only if BepInEx is in the chain. Vanilla Valheim ignores the BepInEx folder entirely. Starting with the vanilla script is a quick way to prove whether mods are the problem.
My world will not load. Will restoring the .old file lose progress?
It loses whatever happened between the last two saves - with the default interval, up to thirty minutes. That is usually far less than restoring a day-old backup, so try the .old pair first.
How much free disk space does a Valheim server need?
Enough for the world several times over: the live .db, its .old copy and the automatic backups all sit beside each other. A few gigabytes free beyond the install is comfortable for most worlds.


