Valheim Dedicated Server Not Loading World? Find the Save
Fix a Valheim dedicated server not loading the world you expect by tracing its -world name, savedir, complete save files, and writable mount.
You will need
- Access to the active server command, service or panel settings
- A stopped server and a separate copy of the expected save
- The exact save path or container volume used by the running process
When a Valheim dedicated server is not loading the world you expect, first compare the active -world argument with the save directory that the running process can actually see. The public server name is separate from the world name, and a -savedir override can point the server somewhere different from the folder you checked. Keep the expected world and any newly created world untouched while you trace those values.
Does the server name choose the Valheim world?#
No. Iron Gate’s dedicated-server guide defines -name as the server name shown to players and -world as the world to load or create. A familiar listing name can therefore sit in front of a newly created world if the process uses a different -world value or save path.
Inspect the command or settings that launched the process that is running now. A saved script, panel form, service unit, container environment, and the command line of the live process can disagree. Record the exact -name, -world and -savedir values, along with the process start time. Do not change all three at once: one verified difference is enough to explain why the expected save is not opening.
If the process exits before it reaches Game server connected, use the focused Valheim server startup checklist. If it stays up and loads the correct world but friends cannot join, use the Valheim connection fix ladder. Those symptoms need different checks from world selection.
Preserve both worlds before you investigate#
Stop the server cleanly before you copy or compare its files. The official guide says a clean Ctrl+C shutdown saves the world. A live process can still write while you copy, leaving you with a partial or inconsistent copy. Keep the original, the unexpected world, and a separate test copy in different locations; note each copy’s path and time.
Do not delete or rename the new world just because it looks empty. It can be useful evidence: its folder may reveal which directory the server actually uses. Do not upload the expected save over the active world while the process is running. If the world matters to your group, first make an independent backup with the operator’s documented method and confirm the copy completed.
Trace the save path used by the running process#
Check the effective -savedir value first. Iron Gate documents it as an override for the save location. When it is absent, the documented defaults differ by operating system: Linux uses ~/.config/unity3d/IronGate/Valheim; Windows uses ../%USERPROFILE%/AppData/LocalLow/IronGate/Valheim. The ~ or %USERPROFILE% belongs to the account running the server, which may not be your interactive login.
Follow the actual process, not just a default path from an old guide. Check the service account or container user, the server’s working directory, the command line passed to it, and any path setting supplied by a panel or wrapper. A panel may translate a field into a command or mount behind the scenes; ask its support to identify the process-visible path if its settings do not show it. Do not assume that a path on the host is the path inside a container.
For Docker, inspect both the image’s documented data path and the container’s current mount mapping. In the maintained community-valheim-tools/valheim-server image, the documented configuration mount is /config, and WORLD_NAME selects a world directory inside its worlds_local/ folder for current saves. A panel or another image can use a different convention. The image’s own README says its environment-variable names are case-sensitive; that does not establish filesystem case behavior for every host or panel.
If you use this image and want to understand its persistent storage before changing anything, the Valheim Docker setup and restore guide explains how its volumes relate to a container. Keep the diagnosis grounded in your own container inspection: a correct variable cannot load files that are outside the mounted volume.
Match the world name to the complete save#
Compare the active world selector with the save’s actual name and location. For the official server, check -world; for the community Docker image above, check WORLD_NAME and its documented directory. Match spelling and punctuation exactly, and check whether the upload added an extra enclosing folder. A path such as worlds_local/MyWorld/MyWorld/... is not the same layout as worlds_local/MyWorld/... when the server expects the latter.
Valheim 1.0 changed world storage from the older .db and .fwl pair to a folder structure with world data split into chunks, according to the official 1.0 announcement. Keep the entire matching save folder together for a current world. For an older save, keep its matching .db and .fwl files together. Do not combine files from a fresh world with files from the intended save, or infer that one similarly named file is a complete backup.
Compare the folder contents and timestamps with the stopped source copy. If the names differ, first correct the selector in a test configuration or copy the save into a new isolated test path. Do not rename the only original copy. Do not assume capitalization alone is the cause: in one Linux l-1.0.17 check, lowercase -world i10clean20261013 opened the existing I10Clean20261013 save directory. That single result does not establish how another version, wrapper, or panel resolves names. The community Docker image’s case-sensitive environment-variable names describe its settings interface, not the case behavior of a mounted filesystem.
Verify the mount and write access without changing the original#
A save can exist on the host and still be invisible to the server if the mount points somewhere else. Inspect the running container’s mount source and destination, then check the expected world under the destination path from inside that container. For a managed panel, ask which host directory is mounted into the game process and which account writes it. Record both sides of the mapping before copying data.
Then check write access using a separate copy and the same runtime user as the server. Look for an explicit permission or read-only error in the server log, confirm the mount is writable, and test a clean save on the disposable copy. A container running as root can appear to work even when a non-root deployment would fail, so the result only applies to the user and mount you tested. A panel’s user, a Docker image’s user, and the host shell user may all differ.
Do not apply recursive chmod or chown commands to a live save as a first fix. If the process cannot write, correct only the confirmed owner or mount setting using the image or provider’s documented procedure, and retest with the copy. The maintained Docker image documents a permission issue during one version’s save conversion; that is a specific maintainer report, not evidence that every new-world symptom is a permissions problem.
Prove which copy loaded and whether it saves#
Use the preserved copy in an isolated test directory and a separate server instance or stopped test container. Keep the test private and do not expose its ports. Start it once, confirm the effective world name and save path in the logs or process settings, and check that it reaches the server-ready line. Compare a known in-game landmark only if a player client can join that test. Without a client-visible comparison, server logs establish which save name the process opened, not what terrain a player saw.
Make one harmless test change only in the disposable world if you have a client, wait for the documented save interval or stop the server cleanly, then start the same test instance again. Check that the same copy opens and that the test change remains. Keep the test isolated so a new world created by a typo cannot replace your group’s current campaign.
In our October 14, 2026 checks, the Linux l-1.0.17 server opened a copied 1.0 world with -world I10Clean20261013 and an explicit -savedir, then wrote the next save generation when stopped. A separate container using the maintained community image logged the same world name, reached Game server connected, wrote save files into its inspected writable /config bind mount after shutdown, and reopened that world after restart. The copied save changed; its original source hashes did not. We had no client in this test, so we did not verify a player-visible landmark or a player-made change. These results show server-side path selection and save behavior in those test setups; they do not establish your panel’s mapping, user permissions, or a successful join.
If the server opens the expected name but reports a load error, or your test copy lacks matching save data, stop before trying repair steps. Keep the source and the generated world separate, and collect the first relevant log lines with passwords, addresses, and account details removed. A world-name mismatch, an invisible mount, a write failure, a partial copy, and damaged save data have different causes; the symptom alone cannot choose among them.
Keep the next test narrow#
Change one confirmed value at a time: world selector, save path, mount mapping, or write access. Record the original value and test only against the copy. If the server opens the intended world after one change, preserve that configuration and repeat the restart check before letting players use it. If the same result remains, reverse the change and move to the next evidence-backed branch instead of repeatedly uploading the same files.
Game Hosting’s Valheim panel includes world administration and import/export controls described on its Valheim hosting page. Those controls can help an operator manage a world copy; changing hosting does not by itself identify or repair a mismatched save path. Choose any hosting option based on its documented storage and backup workflow, and keep a copy you control before replacing an active world.
Quick answers
Does the public server name select the Valheim world?
No. The official dedicated-server arguments use -name for the server listing and -world for the world to load or create. Check the active process or panel command rather than changing the browser name.
Why did the server create a new world after I uploaded mine?
It may be looking in a different save directory, using a different -world value, or seeing a nested or incomplete copy. Stop it, preserve both copies, and compare the effective path and world name before replacing anything.
Can a read-only volume stop Valheim progress from saving?
A process that cannot write to its actual save location cannot complete a save there. Check the mounted path, process user, write errors, and a disposable save on the same environment; do not change broad permissions based on the symptom alone.
Should I delete the new world to make Valheim load my old one?
No. Keep both worlds unchanged until you confirm which path and files the server used. Make a separate backup, then test the intended copy in an isolated save directory.