Quick Answer
Keep access and privilege separate, and audit in order. The captured command reference documents the working set: /setaccesslevel "PlayerName" "admin" grants, /removeadmin "PlayerName" revokes, /banuser "PlayerName" removes — with admin, moderator, overseer, gm, and observer as the five access levels. Protocol: back up the profile and account data first, confirm the player's ORDINARY login works, then grant the smallest role that covers the job, and log who changed what, when. A player who can't join won't be fixed by admin rights — fix account or branch issues first.
Table of Contents
Privilege audit
Do an ordinary login before touching privileges. Use setaccesslevel only after the account is known to work, and record removals and bans separately.
| Stage | Command or check | Write down |
|---|---|---|
| Normal access | Join without admin privilege | Account, profile, result |
| Grant | /setaccesslevel "PlayerName" "admin" | Who granted it, when, why |
| Narrow role | Moderator, overseer, gm, or observer when appropriate | The minimum role needed |
| Remove | /removeadmin "PlayerName" | Return to ordinary access |
| Ban | /banuser "PlayerName" | The action and the reason, kept separate |
The five access levels, and when each is the minimum
The captured administrator reference lists five access levels: admin, moderator, overseer, gm, and observer. 'Minimum necessary' is the rule — each row is the situation, not a hierarchy to climb.
| Level | Grant it when | The caution on record |
|---|---|---|
| Observer | Someone needs to see server state for support or moderation review without acting | The safest grant — visibility without power. Default for 'help me watch the logs' requests |
| GM (game master) | A trusted player needs in-game intervention powers for events or unsticking | GM powers touch the world; grant per-need and remove after, not as a standing perk |
| Overseer | Senior moderation with broader scope than a single event | Name the scope in your log entry — 'overseer' with undefined scope drifts into admin-in-practice |
| Moderator | Day-to-day player moderation: disputes, minor interventions | The workhorse level — most moderation fits here without admin's configuration power |
| Admin | Configuration, whitelist, and server-level changes — the full set | Full power includes the destructive parts. /setaccesslevel "Name" "admin" then /removeadmin when the task ends; standing admins should be fewer than the reasons for them |
Why ordinary login comes first
The captured reference treats ordinary account access and administrator privilege as separate server records — and the order between them is the difference between a fixed player and a corrupted audit trail.
When a player can't join, the tempting move is to grant admin to 'let them in'. It doesn't work, and it poisons the record: the player's problem is account access, branch mismatch, or mod-set mismatch — none of which an access level fixes. What it does do is create a grant entry in your log for a player who couldn't even connect, which is exactly the noise that makes a later audit useless. Fix the join first: account, branch and build, then the mod fields.
Once the ordinary login works, grants become meaningful — and reversible. The command set on record is small and complete: /setaccesslevel for granting (with the level named in quotes), /removeadmin for returning someone to ordinary access, /banuser for removal. The log discipline that makes the set safe: who ran the command, when, against whom, and why — with the ban reasons kept separate from the grant reasons, because 'we banned the griefer' and 'we granted the moderator' are different stories a future you will need to tell apart.
The backup boundary matters here too: privilege changes touch the server profile and account data, so the pre-change backup is your undo button. The backup reference treats the live save folder, server configuration, Workshop and Mods records, copy date, and a tested restore as distinct fields — an access-control change is a configuration change, and it deserves the same dated copy as a settings edit.
Reference data
Access and privilege are separate records. PZFans provides concrete command examples and access levels, while the page keeps an ordinary login test before any administrator grant.
| Action | Command or check | Expected result |
|---|---|---|
| Grant admin | /setaccesslevel "PlayerName" "admin" | The named player receives the intended level |
| Remove admin | /removeadmin "PlayerName" | The player returns to ordinary access |
| Ban | /banuser "PlayerName" | A player access action, recorded separately |
| Access levels | admin, moderator, overseer, gm, observer | Pick the narrowest role for the task |
| Ordinary login | Join with normal access before granting a role | Connection works without admin privilege |
FAQ
What are the Project Zomboid admin commands?
The core set on record: /setaccesslevel "PlayerName" "admin" to grant, /removeadmin "PlayerName" to revoke, /banuser "PlayerName" to ban — with admin, moderator, overseer, gm, and observer as the five access levels. Grant the smallest level that covers the task, and log who ran what, when, why.
Should I give admin to a player who can't join the server?
No — it doesn't fix the problem and it corrupts your audit trail. A join failure is account access, branch/build mismatch, or mod-set mismatch; none of those are changed by an access level. Fix the ordinary login first (account, then branch, then the WorkshopItems/Mods comparison), and only grant privilege to players who can actually connect.
What's the difference between the admin access levels?
Scope. Observer sees server state without acting (the safest grant for support requests); moderator handles day-to-day player disputes; gm holds in-game intervention powers for events; overseer is senior moderation with a named scope; admin is the full configuration-and-destruction set. Standing admins should be fewer than the reasons for them — use /removeadmin when the task ends.
How do I remove an admin safely?
/removeadmin "PlayerName" returns the account to ordinary access — run it as soon as the task that justified the grant is done, and log both the grant and the removal with timestamps. Back up the profile and account data before privilege changes: they're configuration changes, with the same dated-copy rights as a settings edit.