RE:NODE

Valheim server crashes on start: causes and fixes

By RE:NODE Team
12 min read


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 runsWhere the log is
Panel (Pterodactyl and similar)The console tab, live; earlier output in the server's log view
Linux, by handThe terminal, or the file given to -logFile
Linux, systemd servicejournalctl -u valheim -n 300 (your unit name)
WindowsThe console window, or the -logFile path
With BepInExAlso 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:

code
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:

start_server.sh
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=$templdpath

Things that break it:

  • Running the binary directly. Calling ./valheim_server.x86_64 from a systemd unit or your own script without setting LD_LIBRARY_PATH skips the fix. Either run start_server.sh, or set the same variables in your unit with Environment=.
  • Relative paths from the wrong directory. ./linux64 is relative. A service that does not set its working directory to the server folder looks in the wrong place. Set WorkingDirectory= in the unit.
  • `SteamAppId` missing. 892970 is the game's app ID (the server's install ID is 896660). 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 copy linux64/steamclient.so into 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 - EndOfStreamException and similar - followed by the server exiting.
  • A .db file that is zero bytes, or far smaller than yesterday's.
  • A .fwl that 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:

  1. Stop the server. Copy the whole worlds_local folder somewhere safe before touching anything.
  2. Rename the damaged Name.db aside, then copy Name.db.old to Name.db. Do the same with the .fwl if it is the damaged one.
  3. Start and check the log for the world loading.
  4. 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, 2476 and 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:

bash
$ ss -ulpn | grep -E ':245[6-8]'$ pgrep -a valheim_server

If 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.sh on Linux. Starting from start_server.sh runs vanilla - no crash, but no mods either, which leads to a different confusion.
  • The script will not run. Permission denied means it is not executable: chmod +x start_server_bepinex.sh. bad interpreter: /bin/bash^M means it was saved with Windows line endings; convert it with dos2unix or re-extract the pack.
  • Missing pieces. The pack's doorstop_libs folder and, on Windows, winhttp.dll must 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 MissingMethodException or TypeLoadException as 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:

bash
$ dmesg -T | grep -i -E 'out of memory|killed process'$ journalctl -k | grep -i oom

A 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:

  1. Give it more memory. Sizing by group and world age is in how much RAM a Valheim server needs.
  2. Remove heavy mods to test. Content mods add prefabs and memory; a world that loads vanilla and dies modded has its answer.
  3. Check for runaway growth. If the .db has 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:

  1. Stop it. Do not let it keep trying.
  2. Copy the log and the worlds_local folder off the server.
  3. Change one thing - remove plugins, restore the .old world, 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 +quit to repair it.
  • Permissions. A server folder copied as root and run as another user cannot write its world or log. chown -R the 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.