Fix: Bans Disappear After a Restart (writeid Not Saving)

You ban a cheater, they are gone for the evening — then after a restart they reconnect as if nothing happened. A ban that does not survive a restart is a ban that was never written to disk, or a file that is never re-read at boot. Both halves matter: banid alone only bans the running server. This covers the write step, the reload step, and the permission trap that defeats both on Linux.

1. Ban, then write — two separate actions

banid adds a ban to memory only. To put it on disk you must call writeid:

banid 0 STEAM_0:1:12345678 kick
writeid

The 0 is permanent (minutes; zero means forever), and writeid rewrites the SteamID ban file. Skip writeid and the ban lives only until the next map change or restart — which is precisely the symptom. The same applies to IP bans with addip then writeip. The full command set is in the AMX ban commands guide.

2. If you ban through AMX Mod X

The AMXX amx_ban command bans by SteamID and issues writeid for you, so persistence should be automatic. If amx_ban bans work in-game but still evaporate on restart, the problem is not the command — it is either the file not being reloaded (step 3) or the server being unable to write the file (step 4).

3. The saved file must be re-read at boot

Writing the file is only half the job: the engine does not load ban files at startup unless server.cfg execs them. Confirm those lines exist:

exec listip.cfg
exec banned.cfg

Without them, the ban is safely on disk and simply never loaded — covered in detail in banned.cfg not loading. A ban that persists in the file but not in behaviour is always this.

4. The Linux permission trap

On Linux, if the server process cannot write to cstrike/, writeid fails silently — no error to the admin, and the file is never updated. Check ownership and that the user running HLDS owns the directory:

ls -l cstrike/banned.cfg
id   # the user your server runs as
chown steam:steam cstrike/banned.cfg cstrike/listip.cfg

If the file is owned by root but the server runs as steam, the write is denied and every ban is lost on restart no matter how correct the commands are. Fix the ownership and re-issue the ban plus writeid.

5. Verify the write actually happened

Immediately after writeid, the SteamID should be a line in the file:

grep 12345678 cstrike/banned.cfg

A match means the write succeeded. No match, with a correct command, means the permission problem in step 4.

6. Prefer a ban manager for durable bans

The engine ban files work, but they are fragile: one forgotten writeid, one wrong file owner, one missing exec, and bans leak. If you run a busy server where bans matter, a database-backed ban system removes every one of those failure modes at once — the ban is a row in a table the moment you issue it, with no separate write step and no file to exec. That is the whole point of moving to AMXBans or a similar manager; the trade-offs between the approaches are laid out in ban systems compared. Whichever you choose, the rule is the same: a ban is not durable until it exists somewhere that is read back at startup, whether that is an exec'd file or a queried table. Test that read-back once and you never wonder again.

Common errors

• Ban gone after restart, file empty — you never ran writeid/writeip, or the server cannot write the file. Check both.
• Ban in the file but gone after restart — the file is not exec'd at boot; add the exec lines.
• writeid runs but the file never changes — a permission problem; the file is owned by the wrong user. chown it to the server's user.
• Ban lasts one map, not one restart — a temporary banid with a non-zero minute value, or no write at all. Use 0 for permanent and write it.
• Everything else fine, still lost — you keep backups of configs but overwrite the ban file from a stale copy on deploy; see backing up configs and bans.

Verification

Ban a test SteamID, run writeid, and grep the file to confirm the line is there. Restart the server cleanly, run listid, and confirm the ban is listed. Finally reconnect the banned client — refused at connect means the ban wrote, saved, and reloaded correctly. If grep shows the line but listid after restart does not, your exec is missing; if grep shows nothing at all, it is the write permission.