Project Zomboid: \"File Doesn't Exist On The Client\" On A Linux Server

You set up a modded Project Zomboid server, the mods download correctly, the server starts clean, and then players get kicked at the login screen with:

File doesn't exist on the client: <some lua file>

The frustrating part is that the file usually does exist on the client. Here is what is actually happening.

The real cause on Linux servers

Project Zomboid verifies that server and client are running identical Lua code by hashing the Lua files on both sides and comparing the checksums. If they differ, it refuses the connection.

The problem is that a Linux server and a Windows client do not necessarily walk the mod file list in the same order or with the same case handling. Same files, same mods, different sort order going into the hash, so the two sides produce different checksums and the connection is rejected. Nothing is actually missing.

This became a lot more visible from Build 42.13.2 onward, and it hits Linux-hosted servers with Windows players specifically, which is most rented hosting.

The fix

Set DoLuaChecksum to false in your server config.

In your .ini config file (for example servertest.ini, or whatever your server's config is named), find:

DoLuaChecksum=true

Change it to:

DoLuaChecksum=false

Restart the server and players should connect.

One important caveat

DoLuaChecksum exists for a reason. It catches genuine mod mismatches, where a player really is running a different version of a mod than the server.

If your error was caused by the Linux/Windows sort-order issue, turning it off is a correct fix and costs you nothing. If your error was caused by an actual mod version mismatch, turning it off does not fix the mismatch, it just stops the game from warning you about it, and you may get strange gameplay bugs or errors later instead of a clear message at login.

So before you flip it: make sure your mod list is genuinely consistent. If only some players get the error and others connect fine, suspect a real mismatch on those players' end first.

Save yourself the next three hours

While you are in the config, these are the other Build 42 mod issues that produce similar "the mods are clearly there but it does not work" symptoms:

Mod IDs are case sensitive. If you see Mod "X" not found, compare your entry against the Mod ID in the Workshop page description character for character. This is not the same as the Workshop item ID.

You need both lines, not one. Every mod needs its Workshop ID in WorkshopItems= and its Mod ID in Mods=. Getting one and not the other is the single most common setup mistake:

Mods=ModIDOne;ModIDTwo
WorkshopItems=WorkshopIDOne;WorkshopIDTwo

Both lines are semicolon separated, and the Mod ID comes from the mod's Workshop description while the Workshop ID is the number in the mod's URL.

The server rewrites its own config on shutdown. If you edit the config while the server is running, your changes get overwritten when it stops. Always stop the server first, then edit, then start.

Force a mod update when a mod goes stale. Unsubscribing and resubscribing on the client forces Steam to re-download it, which resolves cases where a partially updated mod is producing the mismatch.

Still stuck?

Work through it in this order, it saves time:

1. Stop the server before editing anything.
2. Confirm every mod appears in both Mods= and WorkshopItems=.
3. Confirm Mod IDs match the Workshop description exactly, including capitalisation.
4. If only specific players fail, have them unsubscribe and resubscribe to the mods.
5. If all players fail on a Linux server, set DoLuaChecksum=false.

Space-Node's Project Zomboid hosting runs Build 42 with full config file access through the panel, so you can make all of the above changes yourself in a couple of minutes. If you would rather we look at it, open a ticket with your mod list.

Related: Build 42 stable, what changed and how to update, Project Zomboid dedicated server setup guide

---

Running a modded Zomboid server? View Project Zomboid Hosting Plans