How to Configure Admins and ACL Permissions in MTA:SA
Technical guide to configure admins and ACL permissions in MTA:SA — edit acl.xml, create groups, assign accounts and harden the server against privilege escalation.
The MTA:SA permission system is controlled by an XML file called acl.xml that defines groups, accounts and granular rights per resource. Configuring admins correctly is what separates a server that accepts organized moderation from one that becomes no-man’s-land — or worse, gets vulnerable to privilege escalation because someone received general.ModifyOtherObjects without realizing what it allows.
This tutorial covers the full cycle: create accounts in the MTA internal database, define admin and moderator groups with distinct scopes, map permissions in acl.xml without exposing the admin resource to regular users, and validate everything in-game before releasing it to the team. Estimated time: 20-30 minutes.
The target persona is an MTA:SA server owner who already has mtaserver running and needs to configure the moderation team for the first time. The commands assume a Linux server (Ubuntu 24.04 LTS), but the acl.xml content is identical on Windows.
Prerequisites
MTA:SA server already installed and running, access to the server configuration directory (mods/deathmatch/), active console shell (mtaserver terminal or in-game client with admin login) and the admin resource installed and started.
Make sure you have access to all of this before proceeding:
mods/deathmatch/acl.xml mods/deathmatch/internal.db admin mtaserver stdin The acl.xml is edited while the server is stopped. For runtime changes, use the aclgroup, aclrights and aclrequest console commands — they persist correctly without conflicting with MTA’s autosave.
Understand the acl.xml structure
The acl.xml has three main blocks: <group> (associates objects to ACLs), <acl> (defines granular permissions) and the referenced objects (users, resources). The relationship is: a group contains objects and ACLs; objects are who gets the permissions; ACLs are the permission packages.
A fresh MTA server has this default layout in acl.xml:
<acl>
<group name="Admin">
<object name="user.admin"/>
<object name="resource.admin"/>
<acl name="Admin"/>
<acl name="Moderator"/>
<acl name="RPC"/>
</group>
<group name="Moderator">
<acl name="Moderator"/>
<acl name="RPC"/>
</group>
<group name="Everyone">
<object name="user.*"/>
<object name="resource.*"/>
<acl name="Default"/>
</group>
</acl>Note that Everyone includes user.* and resource.* with the Default ACL — that’s the permission floor for any login. The Admin group adds specific ACLs on top, inheriting what Everyone already provides.
Create the admin account
Connect to the server console. If you use systemd, access via socket:
sudo systemctl status mtasaTo send commands, you need the console attached. On servers running via screen or tmux, reattach to the session:
screen -r mtaserverIf you use systemd with stdin redirected, the method varies by setup — the most common approach is to log into the server in-game as any player, authenticate once with the default admin account and use the commands via chat with /.
Create the new account with a strong password (minimum 12 characters, mixing letters, numbers and symbols):
addaccount adminname StrongPasswordHere123!The response Account 'adminname' created successfully confirms that the credential was saved in internal.db. The password is stored with SHA-256 hashing — it cannot be recovered, only reset.
The admin account with admin as password that ships by default is the most exploited intrusion vector on new MTA:SA servers. Change the password immediately or delete the default account after creating yours: delaccount admin.
Add the account to the Admin group via console:
aclgroup add Admin user.adminnameThe command edits acl.xml at runtime without requiring a restart. Confirm with:
aclgroup listYou should see adminname listed inside the Admin group.
Create custom groups with granular permissions
The default only ships Admin and Moderator. For larger teams you want fine-grained separation — junior staff (support) shouldn’t have ban, an event leader needs setSkin and giveMoney but not unlimited setMoney, and so on.
Stop the server to safely edit acl.xml:
sudo systemctl stop mtasaOpen the file in your editor:
sudo nano /opt/mtasa/mods/deathmatch/acl.xmlAdd a Support group with restricted scope. Insert before the final </acl> of the file:
<group name="Support">
<object name="user.support1"/>
<acl name="Support"/>
<acl name="RPC"/>
</group>Next, define the Support ACL with the minimum rights. Locate the <acl name="Moderator"> block and add a new one right after it:
<acl name="Support">
<right name="command.kick" access="true"/>
<right name="command.mute" access="true"/>
<right name="command.unmute" access="true"/>
<right name="command.warn" access="true"/>
<right name="resource.admin" access="true"/>
<right name="general.ModifyOtherObjects" access="false"/>
</acl>The general.ModifyOtherObjects="false" directive is critical — without it, any role with access to the admin panel can promote/remove other users, including escalating to Admin.
general.ModifyOtherObjects allows a user to edit other users’ permissions via the admin panel. Grant it ONLY to the highest-trust Admin group. Support, moderators and event staff must NEVER have this right — otherwise any of them can self-promote to Admin.
Save the file (Ctrl+O, Enter, Ctrl+X in nano) and start the server:
sudo systemctl start mtasaCheck in the log that acl.xml loaded without a parsing error:
sudo journalctl -u mtasa -n 50 --no-pagerLook for lines like ACL loaded successfully or the absence of ACL parse error.
Assign accounts to the right groups
With the groups defined, you still need to populate them. Create accounts for the remaining members and put each one into the appropriate group.
In the console (or in-game with /), create each new account:
addaccount moderator1 StrongPass001!
addaccount moderator2 StrongPass002!
addaccount support1 StrongPass003!Assign each account to the corresponding group:
aclgroup add Moderator user.moderator1
aclgroup add Moderator user.moderator2
aclgroup add Support user.support1Each command edits acl.xml at runtime and persists. Confirm with aclgroup list — you should see the accounts distributed across the correct groups.
Don’t reuse passwords across staff accounts. If one account leaks (phishing, forum reuse, database leak), all the others become compromised. Consider a tool like Bitwarden or KeePassXC for the team to manage credentials.
Verify permissions in-game
The configuration is only valid if the actual behavior matches the design.
Connect to the server with each test account and authenticate:
/login moderator1 StrongPass001!You should get the message You successfully logged in as moderator1 in the chat. Open the admin panel with /admin or the P key — the panel should appear with only the tabs and buttons that the group’s ACL allows.
Test each granted permission and each DENIED permission. For Support, for example:
- Try to
kickanother player → should succeed - Try to
bananother player → should fail withAccess denied - Try to open the admin management tab → should be missing or blocked
If something allows what it shouldn’t, review the ACL in acl.xml — most likely an extra <right> slipped through or a group inherits more than it should.
Troubleshooting
Login works but I don’t have admin permission
The account was created but isn’t in any group with power. Add it with aclgroup add Admin user.youraccount in the console and test again.
Admin panel opens but buttons are grayed out
The admin resource is accessible but your group’s ACL doesn’t have general.ModifyOtherObjects or enough rights in command.*. Check in acl.xml that your admin group has the Admin and Moderator ACLs listed.
ACL parse error in the log
The acl.xml has invalid XML — an unclosed tag, an attribute without quotes, a loose reserved character. Use an XML validator before starting the server. The command xmllint --noout /opt/mtasa/mods/deathmatch/acl.xml (install with sudo apt install libxml2-utils) points to the exact line of the problem.
Changes in acl.xml disappear after restarting
You edited the file while the server was running. MTA periodically rewrites acl.xml and overwrites manual changes. Always stop the server before editing by hand, or use the aclgroup/aclrights console commands which persist correctly.
Next steps
With ACL configured, it’s worth hardening other layers: enable <password> in mtaserver.conf so no one can join without authorization, configure acl.xml with <right name="resource.runcode" access="false"/> in the Everyone group (the runcode resource allows remote Lua execution and is a critical vector if exposed), and invest in moderation logging via a custom resource that records all staff actions.
If you’re running this at scale — an active community with multiple moderators online simultaneously — a Hostini VPS with a Brazilian IP and volumetric attack protection ensures your infrastructure handles a packed RP event without hiccups. Check out the plans at /jogos.
Frequently asked questions
What is the difference between ACL and Admin in MTA:SA?
ACL (Access Control List) is the system that defines who can do what — groups, objects and granular per-resource permissions. Admin is the official resource (`admin`) that provides an in-game interface to moderate players. ACL is the authorization layer; admin is just one of the resources that consumes that layer.
Can I have multiple admin levels with different permissions?
Yes. Create separate groups in `acl.xml` (e.g., `Admin`, `Moderator`, `Support`) and assign distinct ACLs to each group. Each ACL has its own set of `<right>` entries allowing or denying actions. A moderator, for example, can receive `kick` and `mute` but not `ban` or `setMoney`.
Why doesn't my account created via `addaccount` automatically receive admin permission?
Creating an account only registers credentials. You need to add the account to the corresponding group via `aclgroup add Admin user.accountname` in the console, or manually edit `<object name="user.accountname">` inside the group in `acl.xml`. Without this, login works but the account inherits no permissions.
Is it safe to edit `acl.xml` while the server is running?
Editing the file directly during runtime is not recommended — MTA periodically rewrites `acl.xml` and may overwrite your changes. Stop the server before editing manually, or use the `aclrequest`, `aclgroup` and `aclrights` console commands for runtime changes, which persist correctly.
How do I block the `admin` resource from regular players?
In the `Everyone` group (which covers every unauthenticated user), make sure there is no `<right name="resource.admin" access="true"/>`. The default already blocks it, but it's worth auditing. Only explicit groups like `Admin` should have `<right name="resource.admin" access="true"/>`.
What should I do if I lock myself out of admin due to an error in `acl.xml`?
Stop the server (`Ctrl+C` or `systemctl stop mtasa`), edit `acl.xml` manually restoring the `Admin` group with `<right name="general.ModifyOtherObjects" access="true"/>` and add your account as an object. Bring the server back up and revalidate with `/login` in-game.