Project Zomboid admin commands, access levels and safehouses

Project Zomboid has no RCON. Administration happens in two places: the server console, and the in-game chat box of a character logged in on an account with an access level. The account is called admin by default, its password is set at first start, and everything else - kicks, bans, whitelists, item spawns, weather, safehouse disputes - runs through about forty slash commands and one in-game panel.

That is the whole model, and it has two consequences worth knowing before you hand anyone a password. There is no remote admin protocol to secure or to leave exposed, which is one fewer thing to get wrong. But there is also no way to run a command without being connected to the server or standing at its console, and no built-in way to give somebody the ability to kick without also giving them a character with powers. This guide covers the account, the five access levels, the command reference, bans and whitelisting, the safehouse system that causes most of the arguments, and the logs you will need when somebody says it was not them.

Setting up the admin account#

The first time a dedicated server starts it asks for an administrator password on the console and will not continue until it has one:

Enter new administrator password:Confirm the password:

The username is admin. Hosts that start the server for you pass the credentials as launch arguments instead (-adminusername and -adminpassword), which is why a panel-installed server never shows that prompt. On RE:NODE the admin password is generated per server at install rather than shipped as a default, and is shown with the server's other generated credentials.

To use it, connect to your own server and log in with admin and that password rather than creating a character the normal way. The account exists already, so a wrong password is rejected rather than silently creating a second account.

Two things to get right straight away:

• Change the password if it was ever typed into a chat window. /changeoption cannot do this; stop the server and set it in the launch arguments or the panel's Startup tab.
• Do not play on the admin account. Admin powers attach to the character, so it is easy to leave invisibility or god mode on and then wonder why nothing can hurt you. Keep a normal character for playing and log in as admin only to do something.

Promote other people rather than sharing the password:

/setaccesslevel "Bob" "moderator"/grantadmin "Alice"/removeadmin "Alice"

The name is the account name, not the character's in-game name, and the quotes are required when it contains a space. Promotions take effect the next time that player connects.

The five access levels#

Below admin there are four named levels, and a player with none of them is an ordinary survivor:

The uncomfortable part is that the exact split has never been documented precisely by the developers and has moved slightly between builds. Treat the table as the intent rather than the specification, and before you hand gm to someone, log in on a test account at that level and try the two or three things you care about. The same caution applies to guides listing which command needs which level: check on your own server, on your own build.

The general principle is the one from subusers and least privilege: the person who runs your event nights needs gm, not admin, and the person who handles arguments at 2am needs moderator, not both.

Command reference#

Commands are typed into the in-game chat with a leading /, or into the server console. Arguments containing spaces go in double quotes. The server confirms each command in the console, which is the quickest way to tell a typo from a permissions problem.

Players and moderation:

Players and the world:

Server and maintenance:

Item names are module.type, almost always Base.Something, and they are case sensitive. Vehicle names are the Base.* vehicle scripts. Perk names for /addxp are the internal ones: Woodwork, Cooking, Fitness, Strength, Sprinting, Aiming and so on, not the display names with spaces.

Whitelisting, accounts and the user database#

Two separate things control who gets in, and people mix them up constantly.

Password= in the ini is a single server password typed at connection. It keeps strangers out and nothing else.

Open= decides how accounts work. With Open=true, the default, a new player types a username and password on first join and the account is created for them. With Open=false, only accounts that already exist can connect, and you create them yourself:

/adduser "Bob" "a-password-you-tell-Bob"/addusertowhitelist "Bob"

For a server that is already running with Open=true and a group of regulars, the quickest way to close it is to have everyone connect once, run /addalltowhitelist, then set Open=false and restart.

All of this lives in a SQLite database at Zomboid/db/<servername>.db - accounts, password hashes, access levels and bans. Two practical consequences: deleting that file resets every account including admin, and copying it is how you move your user list to a new server without making everyone register again. Back it up along with the save, not instead of it.

Bans by account are trivially defeated by making a new account on an open server, which is why /banid exists. The Steam ID appears in the server logs for every connection, so the sequence for a repeat offender is to find the ID in the log, /banid it, and then ban the account as well so the name is recorded.

The in-game admin panel#

Logged in at a sufficient level, you get an admin button in the game's interface. The panel is the practical interface for the things that are painful to type:

• Players: the connected list with positions, with teleport, kick and access level in a menu.
• Items and vehicles: a searchable spawn list, which saves you looking up Base. names.
• Sandbox options: the live sandbox values, editable without a restart. This is the fastest way to change zombie population or loot rarity for an experiment, and the changes apply to the running world.
• Safehouses: the claimed list, with the owner and members, and a release button.
• Database: the account list, where you can change a level or a password without the command.

Anything you change here happens immediately and is written into the save, not into <servername>.ini or <servername>_SandboxVars.lua. That is the trap: a value changed in the panel survives restarts because it is in the save, so when the file and the game disagree, the save wins. If you want a setting to be permanent and obvious, set it in the file too. The full list of those values is in Project Zomboid server settings.

Safehouses and why they cause arguments#

Safehouse rules are the most social settings on a Zomboid server, and they are all off by default. Every one of these keys lives in <servername>.ini:

Note the capitalisation of SafeHouseRemovalTime, which does not match the others. The ini is inconsistent in a few places, so copy keys out of the generated file rather than retyping them from memory.

The combination that produces a peaceful server is PlayerSafehouse=true with SafehouseAllowTrepass=false and SafehouseAllowLoot=false: a claimed building is genuinely yours and yours alone. The combination that produces complaints is SafehouseAllowTrepass=true with looting allowed, because the claim then protects nothing and people assume it does.

SafehouseDaySurvivedToClaim is worth setting to something above zero on a public server. It stops a fresh spawn claiming the Rosewood fire station five minutes after joining, which is otherwise the first thing that happens. SafeHouseRemovalTime at the default 144 hours means a claim lapses after six real days without the owner - shorten it on a busy server, lengthen it for a group that plays once a week, and tell people the number.

DisableSafehouseWhenPlayerConnected deserves its own warning. It turns protection off whenever a member is online, which sounds fair and means a player standing in their own base can be robbed while they sleep at the wheel. Leave it false unless you are running a PvP server and want raiding to be possible.

An admin standing inside a disputed building can run /releasesafehouse to clear the claim, which is the end of most arguments. Write down that you did it, because the person who lost the claim will ask.

Logs, and proving what happened#

Project Zomboid writes far more than one log. The full console output goes to Zomboid/server-console.txt, and Zomboid/Logs/ holds dated files split by category. The exact set varies by build, but you can expect files for chat, player connections, admin actions, commands run, item transactions, perk changes, PvP and map changes.

The map log is the one people do not know about. It records player-caused changes to the world, which is how you find out who dismantled the generator. The item log is how you find out where the generator went. Between those two and the chat log, almost every griefing dispute is answerable without anyone's word against anyone else's.

Two habits make this work. Pull the logs off the server on a schedule rather than after an incident, because rotation will eventually remove the day you needed - logs worth keeping covers what to retain and for how long. And read the console rather than only searching it; the startup output tells you which mods loaded, which anti-cheat types are active and what the server thinks its settings are. Reading the console goes through that in general.

Anti-cheat and the kicks that are not cheating#

The server ships with a numbered list of anti-cheat checks, AntiCheatProtectionType1 through AntiCheatProtectionType24, each a boolean with a matching ...ThresholdMultiplier. They cover things like impossible movement, teleporting, item duplication and inventory changes that the server did not authorise.

They also produce false positives, and mods are the usual cause. Anything that legitimately moves a player, changes movement speed, or hands out items through a custom interface can trip a check that was written on the assumption that nothing does that. The symptom is a player being kicked repeatedly at a specific moment - entering a vehicle, using a mod's menu - with the console naming the check that fired.

The fix is to disable that specific numbered check, not all of them. Turning the whole list off on a public server means the first person with a cheat table can spawn whatever they like, and you will not find out until the economy is meaningless. If you run a long mod list, see Project Zomboid server mods for how to narrow down which mod is involved, and keeping a modded server clean for the wider hygiene.

DoLuaChecksum is related and different. It kicks clients whose Lua files do not match the server's, which is exactly what you want, and exactly what breaks when a player has an extra client-side mod. Switching it off is a security decision rather than a convenience one: it is the check that stops somebody shipping their own modified game logic.

FAQ#

How do I become admin on my own Project Zomboid server?

Log in with the username admin and the password set at first start, which on a hosted server is generated for you and shown with the server's credentials. If you have forgotten it, stop the server and set a new one in the launch arguments; the account itself lives in Zomboid/db/<servername>.db.

Does Project Zomboid support RCON?

No. There is no RCON port and no remote admin protocol. You administer the server from its console or from a character logged in on an account with an access level, which is why keeping console access limited matters more here than in games where RCON does the job.

What is the difference between a whitelist and a server password?

The password is one shared string typed at connection. The whitelist is per account: with Open=false only accounts that already exist can join, so you create them with /adduser and hand out individual credentials. Use the whitelist if you ever want to remove one person without changing everyone's password.

Can I change sandbox settings without restarting?

Yes, through the admin panel's sandbox options, and the change applies immediately to the running world. It is stored in the save rather than in <servername>_SandboxVars.lua, so update the file too if you want the setting to survive a rebuild.

Why does a player keep getting kicked for cheating?

Almost always an anti-cheat check reacting to a mod. Find the numbered type in the console output and disable that one check in the ini rather than the whole list, then confirm the kick stops before you change anything else.

How do I take away a safehouse someone else claimed?

Stand inside it as an admin and run /releasesafehouse, or find it in the admin panel's safehouse list and release it there. Claims also lapse on their own after SafeHouseRemovalTime hours without the owner, 144 by default.