Add fix-bans-not-persisting/en.md
Browse Source
Daemon666 committed
parent 15fdb15480
commit 56e2dca7043ab4f9d0d4526682d729104348a3ea
1 changed file
with 13 additions and 0 deletions
fix-bans-not-persisting/en.md
A
| @@ -0,0 +1,13 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Bans Disappear After a Restart (writeid Not Saving)" | |
| 3 | +excerpt: "Why a ban vanishes on restart: the write step that saves it to disk, the exec that reloads it, and the Linux file-permission problem that silently drops both." | |
| 4 | +category: "errors" | |
| 5 | +tags: "bans, config" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>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: <code>banid</code> alone only bans the <em>running</em> server. This covers the write step, the reload step, and the permission trap that defeats both on Linux.</p><h2>1. Ban, then write — two separate actions</h2><p><code>banid</code> adds a ban to memory only. To put it on disk you must call <code>writeid</code>:</p><pre>banid 0 STEAM_0:1:12345678 kick | |
| 10 | +writeid</pre><p>The <code>0</code> is permanent (minutes; zero means forever), and <code>writeid</code> rewrites the SteamID ban file. Skip <code>writeid</code> and the ban lives only until the next map change or restart — which is precisely the symptom. The same applies to IP bans with <code>addip</code> then <code>writeip</code>. The full command set is in <a href="/tutorials/amx-ban-commands">the AMX ban commands guide</a>.</p><h2>2. If you ban through AMX Mod X</h2><p>The AMXX <code>amx_ban</code> command bans by SteamID and issues <code>writeid</code> for you, so persistence should be automatic. If <code>amx_ban</code> 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).</p><h2>3. The saved file must be re-read at boot</h2><p>Writing the file is only half the job: the engine does not load ban files at startup unless <code>server.cfg</code> <code>exec</code>s them. Confirm those lines exist:</p><pre>exec listip.cfg | |
| 11 | +exec banned.cfg</pre><p>Without them, the ban is safely on disk and simply never loaded — covered in detail in <a href="/tutorials/fix-banned-cfg-not-loading">banned.cfg not loading</a>. A ban that persists in the file but not in behaviour is always this.</p><h2>4. The Linux permission trap</h2><p>On Linux, if the server process cannot write to <code>cstrike/</code>, <code>writeid</code> fails silently — no error to the admin, and the file is never updated. Check ownership and that the user running HLDS owns the directory:</p><pre>ls -l cstrike/banned.cfg | |
| 12 | +id # the user your server runs as | |
| 13 | +chown steam:steam cstrike/banned.cfg cstrike/listip.cfg</pre><p>If the file is owned by <code>root</code> but the server runs as <code>steam</code>, 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 <code>writeid</code>.</p><h2>5. Verify the write actually happened</h2><p>Immediately after <code>writeid</code>, the SteamID should be a line in the file:</p><pre>grep 12345678 cstrike/banned.cfg</pre><p>A match means the write succeeded. No match, with a correct command, means the permission problem in step 4.</p><h2>6. Prefer a ban manager for durable bans</h2><p>The engine ban files work, but they are fragile: one forgotten <code>writeid</code>, one wrong file owner, one missing <code>exec</code>, 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 <a href="/tutorials/ban-systems-compared">ban systems compared</a>. 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.</p><h2>Common errors</h2><ul><li><strong>Ban gone after restart, file empty</strong> — you never ran <code>writeid</code>/<code>writeip</code>, or the server cannot write the file. Check both.</li><li><strong>Ban in the file but gone after restart</strong> — the file is not exec'd at boot; add the <code>exec</code> lines.</li><li><strong>writeid runs but the file never changes</strong> — a permission problem; the file is owned by the wrong user. <code>chown</code> it to the server's user.</li><li><strong>Ban lasts one map, not one restart</strong> — a temporary <code>banid</code> with a non-zero minute value, or no write at all. Use <code>0</code> for permanent and write it.</li><li><strong>Everything else fine, still lost</strong> — you keep backups of configs but overwrite the ban file from a stale copy on deploy; see <a href="/tutorials/backup-configs-bans-stats">backing up configs and bans</a>.</li></ul><h2>Verification</h2><p>Ban a test SteamID, run <code>writeid</code>, and <code>grep</code> the file to confirm the line is there. Restart the server cleanly, run <code>listid</code>, and confirm the ban is listed. Finally reconnect the banned client — refused at connect means the ban wrote, saved, and reloaded correctly. If <code>grep</code> shows the line but <code>listid</code> after restart does not, your <code>exec</code> is missing; if <code>grep</code> shows nothing at all, it is the write permission.</p> | |
| 0 | 14 |
