What does "file does not match the one on the server" mean in Project Zomboid?

It is the Lua checksum check. On join, the server compares the checksum of the Lua and script files the client has loaded against its own, and refuses the connection when they differ. The named file is only the first difference it found, not necessarily the cause. Almost always the client and the server are running different game builds, or one side has a different version of a Workshop mod.

How do I fix the Project Zomboid file mismatch error?

Get both sides onto the same build. On a Flux server, open the Game Version tab and update the server to the current patch, or turn on "always run the latest version". On the client, Steam Properties then Game Versions & Betas lets you pick the branch that matches the server. If versions already match, unsubscribe and re-subscribe to the server mods, restart the server, and verify the client game files through Steam.

What is DoLuaChecksum in Project Zomboid?

DoLuaChecksum is a server setting in servertest.ini, on by default, that kicks any client whose game and mod files do not match the server. Setting it to false disables the check and bypasses the file mismatch error. On Flux it is the Lua File Check toggle in the Server Settings tab.

Is it safe to set DoLuaChecksum to false?

It is a workaround, not a fix. The check keeps everyone on identical files, so disabling it lets mismatched - or deliberately modified - client Lua through. Instead of a clean kick you get desyncs, odd item behaviour and crashes mid-session, and a modified client is no longer detected. Use it when the files really do match and the check is a false positive, which is the known Linux dedicated server case, and re-enable it once the underlying mismatch is gone.

Does auto-updating the server prevent the error?

It removes the most common cause. Steam updates player clients automatically, so a server pinned to an older patch drifts behind and starts rejecting players. With "always run the latest version" enabled, the server follows new stable releases on its own and the two sides stay aligned. Workshop mod updates are still worth a restart, since the server picks those up on boot.

Guides / Troubleshooting

Project Zomboid: How to Fix "File Does Not Match the One on the Server"

Name: Project Zomboid Server Hosting
Brand: Flux
Availability: InStock

It is the most frustrating way to end a session before it starts: everyone is in the Discord call, someone hits Join, and Project Zomboid throws them straight back out with a file that supposedly does not match the one on the server. Nothing is broken - the server is doing exactly what it was told to do. This guide explains what the check actually compares, why it fires, how to fix each cause properly, and when it is reasonable to turn it off with DoLuaChecksum.

What the error actually means

When a client connects, the Project Zomboid server compares the checksum of the Lua and script files the client has loaded against its own. If a single file differs, the connection is rejected and the player sees a message naming that file - "file does not match the one on the server", or one of its close relatives like "file doesn't exist on the client" and "Lua/script checksums do not match".

The check is controlled by the server setting DoLuaChecksum, which is enabled by default. Its job is to guarantee that everyone in the session is running the same code: identical game files and identical mods. That matters because Project Zomboid runs a lot of its logic in Lua on both sides, so a client with different files does not simply see something slightly different - it desyncs, throws errors and can corrupt what it writes back to the world.

Two things follow from that, and they save a lot of wasted time:

The file it names is rarely the problem. It is just the first difference the comparison hit. Chasing that specific file leads nowhere; look at why the two sides have different files at all.
It is a symptom, not a fault. Something on one side is a different version. Find which side drifted and the error disappears on its own.

Cause 1: the client and the server are on different builds

This is the cause in the overwhelming majority of cases. Steam updates player clients automatically, usually the moment a patch ships. A server does not - it keeps running the version it was deployed with. The day The Indie Stone pushes a new build, every player is on it by the evening and the server is still on last week's, so the checksums stop matching and nobody can join.

There are two ways to close the gap, and you only need one of them.

Move the server forward (recommended)

On a Project Zomboid server hosted with us, open the Game Version tab in the dashboard. It shows the version the server is on and, when a newer stable patch has been published, offers a one-click update. A patch update keeps the same plan, so your world, your servertest.ini and your settings survive it - only the game files are replaced.

In the same tab you can turn on "always run the latest version". The server then follows new stable releases by itself and simply never falls behind your players again. That is the setting to use if you would rather not think about this at all - and the reason this error is largely a solved problem for our customers. The trade-off is worth knowing: an automatic update can arrive while a mod you rely on has not been updated yet, so heavily-modded communities sometimes prefer to update manually after checking their mod list.

Or move the client back

Sometimes you deliberately want the server to stay where it is - a long-running world, a mod list pinned to a specific build. In that case the player pins their client instead. In Steam, right-click Project Zomboid, open Properties → Game Versions & Betas, and select the version that matches the server: legacy41 for a Build 41 server, the default public version for the current Build 42 stable, or a specific older patch when Steam still lists one. The client downloads that build and the checksums line up again.

Worth stating plainly, because people lose hours to it: a Build 42 client cannot join a Build 41 server, and no setting on either side changes that. The two builds are far enough apart that they are effectively different games in multiplayer. If your group is split, pick a build and have everyone move to it. Our plans cover both - see the server requirements for how the two compare.

Cause 2: Workshop mods out of sync

The second cause is mods, and it behaves exactly the same way: a Workshop item updated on one side and not the other. Mod authors publish on their own schedule, Steam pushes the update to subscribed players immediately, and a running server keeps the copy it downloaded at boot. One player who has not finished downloading - or a server that has not restarted since the update - is enough to trigger the mismatch.

Restart the server after a wave of Workshop updates. Mods are fetched during startup, so a restart is what pulls the current versions. Doing it before a session, rather than during one, avoids the whole problem.
Have the affected player unsubscribe and re-subscribe. Unsubscribe from the server's mods, give Steam a minute to actually remove the files, then re-subscribe and wait for the download to complete before joining. A half-downloaded mod produces exactly this error.
Check the mod is listed correctly server-side. Every mod needs its numeric Workshop ID in WorkshopItems and its text Mod ID in Mods. Our Steam Workshop mods guide covers that pair in detail - the dashboard Mod Manager writes both for you.
Suspect the newest addition first. If the error started right after a mod was added, remove it, restart, and see whether joining works. Some Workshop items ship files that never reach the client cleanly.

Cause 3: corrupted or half-updated client files

Less common, but easy to rule out. If one specific player gets the error while everyone else on the same build joins fine, their local install is the odd one out. Have them open Steam, right-click Project Zomboid, and use Properties → Installed Files → Verify integrity of game files. Steam re-downloads anything that does not match, including a Lua file left behind by an interrupted update. If verification alone does not do it, deleting the media/lua folder inside the game directory and verifying again forces a clean re-download of exactly the files the checksum covers.

Cause 4: the Linux false positive

There is a long-standing quirk where a Linux dedicated server can report a mismatch even though the client and server files genuinely agree. Dedicated servers - ours included - run on Linux, so it is worth knowing this exists. It is not the common case, and you should only conclude you have hit it after the checks above: same build on both sides, mods re-synced, client files verified, and the error still fires.

This is the situation where turning the check off is the right call rather than a shortcut, because there is nothing left to fix - the files match and the comparison is wrong.

The last resort: turning off DoLuaChecksum

Setting DoLuaChecksum=false disables the comparison, so the server stops rejecting clients over file differences. It is the workaround you will find quoted everywhere, and it does work.

On a server hosted with us you do not need to edit anything by hand: open the Server Settings tab and switch Lua File Check off under Access & Admin. The dashboard stops the server, writes the setting and restarts it - Project Zomboid rewrites its own config on shutdown, which is why the change has to be applied that way. Self-hosting? The line lives in servertest.ini:

DoLuaChecksum=false

Before you do, understand what you are giving up. The check is what keeps every session on identical code. With it off:

Genuine mismatches get through. Instead of a clean kick at the door you get desyncs, items behaving differently for different players, and client crashes mid-session - much harder to diagnose than the error you just silenced.
Modified client files are no longer detected. The check is also the thing that notices a player running altered Lua. On a public server that matters.
It does not bridge real version gaps. Disabling the check on a badly outdated server does not make an old server work with a new client - it just moves the failure from a clear message to unpredictable behaviour. Across Build 41 and Build 42 it does not help at all.

The honest recommendation: use it for the Linux false positive, or as a temporary unblock so your group can play tonight while you sort out the real mismatch - then turn it back on. It is a valid tool, just not the first one to reach for.

How to stop it happening again

Let the server follow the game. Turn on "always run the latest version" in the Game Version tab, and the most common cause of this error stops existing.
Restart before sessions, not during them. A restart is what picks up Workshop mod updates. Scheduling it ahead of your group's play time keeps mod drift out of your evening.
Settle the mod list. The more mods, the more independent update schedules you are exposed to. Communities that update mods deliberately, in batches, see this far less than those that add mods continuously.
Agree on one build. Decide Build 42 or Build 41 as a group and make sure every player is on the matching Steam branch.

A server that keeps itself aligned

Every Project Zomboid server deployed on Flux ships with the tools this guide relies on: a Game Version tab for one-click patch updates and automatic latest-version tracking, a Server Settings editor with the Lua file check exposed as a plain toggle, a Mod Manager that resolves Workshop and Mod IDs for you, plus RCON, a console, a file browser and backups. Deployment takes about 30 seconds, with dedicated resources and DDoS protection on a network of nodes in 50+ countries. See the pricing section for the current plans, or the setup guide if your server is not up yet.

FAQ

What does "file does not match the one on the server" mean?

The server compared the Lua and script files your client loaded against its own and found a difference, so it refused the connection. The file it names is just the first difference found, not the cause.

How do I fix it?

Get both sides onto the same build - update the server from the Game Version tab (or enable automatic updates), or pin the client to the server's build in Steam under Game Versions & Betas. If the builds already match, re-sync the Workshop mods and verify the client's game files.

What is DoLuaChecksum?

The server setting, on by default, that performs this check. Setting it to false disables it. On Flux it is the Lua File Check toggle in the Server Settings tab.

Is it safe to turn off?

It is a workaround, not a fix. It lets genuinely mismatched or modified client files through, trading a clean kick for desyncs and crashes. It is the right answer for the Linux false positive, and a reasonable temporary unblock otherwise.

Can a Build 42 client join a Build 41 server?

No, and no server setting changes that. Everyone has to be on the same build - move the server to Build 42, or have players switch to the legacy41 branch in Steam.

Deploy a Project Zomboid server that updates itself →