Fix: 'You have no access to that command' on amx_ban

You type an admin command and AMX Mod X refuses it:

You have no access to that command

This means AMXX either does not recognize you as an admin at all, or it recognizes you but your access flags do not include the one that specific command requires. Every admin command is gated by a flag; being "an admin" is not enough — you need the right flag for that command. The fix is to get your admin entry recognized and give it the flags the command demands.

1. Check whether AMXX sees you as an admin

From in-game, list the recognized admins:

amx_who

This shows every connected player and their access flags. If your name shows no flags (or you are not listed as admin), AMXX did not match you to an admin entry — an authentication problem (step 3). If you are listed but missing a flag, it is a permissions problem (step 2). Read amx_who before assuming which one you have.

2. Map the command to its flag

AMXX commands require specific access flags, defined by letter. The relevant ones for moderation:

• b — reservation / slot access.
• c — kick access (amx_kick).
• d — ban access (amx_ban, amx_banip).
• e — slay/slap access.
• f — map change access.

So amx_ban specifically needs flag d. An admin set up with only c can kick but will get "no access" on a ban. The commonly assigned "full admin" flag string bundles most of these; if your entry has a narrow flag set, widen it to include d for banning.

3. Fix the users.ini entry and its auth mode

Admins are defined in:

addons/amxmodx/configs/users.ini

Each line is an identity, a password, an access-flags string, and an account-flags string that says how to authenticate:

"STEAM_0:1:12345678" "" "abcdefghijklmnopqrstu" "ce"

The last field is where recognition breaks. The account flag decides the auth method:

• c means "this is a SteamID" — authenticate by Steam ID, no password. This is the reliable method for a Steam server.
• d in the account field means match by IP.
• Without c/d/e set appropriately, AMXX expects a password and you must set setinfo _pw "yourpass" in your client config — forget that and you are never authenticated.

The most common failure is a SteamID entry whose account flag does not include c, so AMXX waits for a password that never comes and treats you as a non-admin. Set the account flag to authenticate by SteamID and make sure the SteamID string matches your real ID exactly — find yours with the SteamID guide.

4. Reload admins so the change takes effect

Editing users.ini does nothing until AMXX re-reads it. From the console:

amx_reloadadmins

This reloads the admin list without a map change. Reconnect if your access still is not picked up, since some setups match admins on connect. Then run amx_who again and confirm your flags now include what the command needs.

5. Check the immunity and default-access cvars

Two settings quietly change who can do what. amx_default_access grants a baseline flag string to every connecting player — leave it empty on a public server, because a stray value here can either hand out access you did not intend or, if misconfigured, interfere with how entries are matched. Separately, a target's immunity flag (a) blocks lower admins from acting on them, so a ban that is refused because the target is immune reads differently from "no access to that command" — the command ran but the action was denied. If amx_who shows you hold flag d yet a specific ban still fails, check whether the target carries immunity rather than assuming your own access is broken. Keeping the flag model explicit — who is an admin, what flags they hold, and who is immune — is what stops these three separate refusals from blurring together.

Troubleshooting

• Not listed as admin in amx_who — auth failed. The SteamID does not match, or the account flag does not say to auth by SteamID, or a required password is unset.
• Listed but missing flag d — you are an admin without ban access. Add d to your access-flags string.
• Worked before, broke on a non-Steam server — IDs there depend on Reunion/dproto; an unstable ID no longer matches your users.ini line. Pin the auth method to what those hand out.
• Edited users.ini, still refused — you did not run amx_reloadadmins or reconnect. The file is cached.
• Password mode never authenticates — you set the account flag to expect a password but never set setinfo _pw on your client. Switch to SteamID auth (c) instead.

Verification

After editing users.ini, run amx_reloadadmins, reconnect, and check amx_who — your name should show the full flag string including d. Then run the command that was refused, such as amx_ban on a test target, and confirm it executes instead of printing the access error. If amx_who shows the flags but the command still refuses, the command needs a different flag than you think — re-check the flag it requires. A managed admin suite like the CSB Admin Menu surfaces these flags in a menu so you are not editing the raw file by hand.