Add fix-amxbans-not-banning/en.md
Browse Source
Daemon666 committed
parent 1859dc8457
commit 229d158071cdf6de983b64e444b9a786117675bc
1 changed file
with 14 additions and 0 deletions
fix-amxbans-not-banning/en.md
A
| @@ -0,0 +1,14 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: AMXBans Doesn't Ban / No Rows Inserted in MySQL" | |
| 3 | +excerpt: "Why an AMXBans command appears to work in-game yet writes nothing to the database: the MySQL module, the amxbans SQL config, load order, and table-prefix mismatches." | |
| 4 | +category: "errors" | |
| 5 | +tags: "amxbans, mysql" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You run a ban through AMXBans, the player is kicked, but the web panel stays empty and <code>SELECT * FROM amx_bans</code> returns nothing. The ban lived only in engine memory and vanished on map change. AMXBans is a database ban system, so if no row is inserted, the plugin never reached MySQL. This walks the four links in that chain — module, credentials, load order, table names — in the order they break.</p><h2>1. Confirm the MySQL module is running</h2><p>AMXBans writes through the <code>mysql</code> module. If it is not loaded, every insert silently fails. Check at the console:</p><pre>amxx modules</pre><p>You want a line for <code>mysql</code> reading <code>running</code>. If it is missing, enable it in <code>addons/amxmodx/configs/modules.ini</code> and install it as in <a href="/tutorials/install-mysql-module-amxx">installing the MySQL module</a>. No module, no rows — full stop.</p><h2>2. Check the AMXBans SQL credentials</h2><p>AMXBans keeps its own database config separate from other plugins, under <code>addons/amxmodx/configs/amxbans/</code>. Open the SQL config there and confirm every field:</p><pre>SQL_HOST "127.0.0.1" | |
| 10 | +SQL_USER "csbans" | |
| 11 | +SQL_PASS "..." | |
| 12 | +SQL_DB "amxbans" | |
| 13 | +SQL_PREFIX "amx"</pre><p>A wrong host, password, or database name here is the single most common cause. Watch the AMXX log at map start for the connection result — a failure quotes the MySQL error verbatim, for example:</p><pre>[MySQL] Error: Access denied for user 'csbans'@'localhost' (using password: YES)</pre><p>or, when the account is not allowed from the server's address:</p><pre>[MySQL] Error: Host '203.0.113.10' is not allowed to connect to this MySQL server</pre><p>Fix the grant or the credentials until the log shows a clean connect. This is the same troubleshooting used when setting up the <a href="/tutorials/amxbans-web-panel">AMXBans web panel</a>.</p><h2>3. Verify plugin load order</h2><p>AMXBans ships as several plugins and the core must initialise before the parts that use it. In <code>plugins.ini</code> the AMXBans block belongs together and <code>amxbans_core.amxx</code> must sit above <code>amxbans_main.amxx</code>:</p><pre>amxbans_core.amxx | |
| 14 | +amxbans_main.amxx</pre><p>If <code>main</code> loads first it has no database handle and bans go nowhere. The rules for ordering are in <a href="/tutorials/plugins-ini-load-order">plugins.ini load order</a>. Follow the full install in <a href="/tutorials/install-amxbans">installing AMXBans</a> if you are unsure which lines belong.</p><h2>4. Match the table prefix to the database</h2><p>The <code>SQL_PREFIX</code> value builds the real table names — prefix <code>amx</code> means <code>amx_bans</code>, <code>amx_admins</code>. If you imported the schema with one prefix and configured another, the plugin queries a table that does not exist and the insert errors out. Confirm the tables actually present:</p><pre>SHOW TABLES;</pre><p>and make the prefix in the config match what you see. A mismatched prefix produces "Table 'amxbans.amx_bans' doesn't exist" in the log.</p><h2>5. Trace it end to end when the log is quiet</h2><p>Sometimes the connection succeeds and the tables exist, yet bans still do not appear. When that happens, prove each stage in isolation. First, confirm AMXBans is genuinely the plugin handling the ban and not the stock <code>admin.amxx</code> ban path running in parallel — two ban systems fighting over the same command means your ban may have gone through the engine list instead of the database. Second, watch the AMXX log the moment you issue the ban, not just at map start; a query that fails at ban time prints its own MySQL error there. Third, run the same <code>INSERT</code> the plugin would run directly against the database as the configured user — if that fails by hand, the account lacks <code>INSERT</code> privilege on the table even though it can connect and read. Grant the missing privilege and the plugin's writes start landing.</p><h2>Common errors</h2><ul><li><strong>Player kicked but no DB row</strong> — the ban ran through the engine only. The module or the credentials failed; check the log from map start.</li><li><strong>"Access denied for user"</strong> — wrong password, or the MySQL account lacks rights on that database. Regrant and retest.</li><li><strong>"is not allowed to connect"</strong> — the grant is host-locked. Add a grant for the server's IP, or use <code>127.0.0.1</code> when DB and server share a box.</li><li><strong>"Table ... doesn't exist"</strong> — prefix mismatch or the schema was never imported. Fix <code>SQL_PREFIX</code> or import the SQL.</li><li><strong>Bans insert but reappear after unban</strong> — you cleared the engine list but not the row; unban through AMXBans, see <a href="/tutorials/unban-a-player">how to unban a player</a>.</li></ul><h2>Verification</h2><p>Ban a test SteamID in-game, then query the table directly:</p><pre>SELECT player_nick, player_id, ban_length FROM amx_bans ORDER BY ban_created DESC LIMIT 1;</pre><p>The row must be present with the SteamID you banned. Refresh the web panel and confirm it shows there too. Finally change the map and reconnect the banned client — if the block survives the map change, the ban is genuinely in MySQL and AMXBans is authoritative again. If the row is still missing, the log from the last map start names the exact link that failed.</p> | |
| 0 | 15 |
