A FiveM server can have excellent scripts, a polished map, and a busy Discord—then get derailed because a staff role has more access than it needs. FiveM’s built-in ACE permission system gives server owners a way to control who can run commands or access protected features. The concepts are straightforward once the terminology clicks.
This guide explains principals, objects, inheritance, and rule order in practical terms. It is aimed at server owners and developers who want permissions that are easier to audit, safer to maintain, and less likely to surprise them during a busy session.
What ACE permissions do in FiveM
ACE stands for Access Control Entry. In FiveM, an ACE rule connects a principal—a player identifier, group, or resource—to an object, which is usually a command or permission name. The rule then allows or denies access.
At a high level, the question ACE answers is simple: “May this identity do this thing?” A resource can ask that question with FiveM’s permission checks, while the server configuration defines the answer.
For example, a server may give a moderation group access to a command, while reserving high-impact administration commands for a smaller owner group. The point is not to create a giant permissions file. The point is to make the intended access model visible and deliberate.
The four terms to understand first
Principals
A principal is the identity receiving permissions. It can be an individual player identifier, a named group, or a resource. A typical group principal might be group.moderator; an individual might be identified through a license identifier such as identifier.license:….
Groups are generally the better default for staff access. Assigning rules to every individual staff member is manageable for three people and painful for thirty. Use individual assignments sparingly, such as a temporary exception or a server owner account.
Objects
An object is the permission being checked. FiveM commands commonly use object names beginning with command., such as command.quit. Scripts can define and check their own permission objects too, often using a namespace that makes ownership obvious.
Good object names are specific. A permission such as myresource.staff.teleport communicates far more than a vague, catch-all permission name.
Rules
Rules grant or deny an object to a principal. In server configuration, the core commands are add_ace for a permission rule and add_principal for membership or inheritance.
A simplified example looks like this:
add_ace group.moderator command.somecommand allow
This says that members of group.moderator may use the specified command. The exact command names and permission objects available on your server depend on its resources and configuration, so do not copy a rule blindly just because it appeared in another server’s config.
Inheritance
Inheritance lets one principal receive another principal’s permissions. This is how you avoid repeating the same rules across every role.
For instance, an administrator group may inherit the moderator group:
add_principal group.admin group.moderator
If moderators can use a defined set of support tools, administrators inherit those tools and can receive additional rules of their own. Think of it as a role ladder, not a pile of unrelated permission lists.
Build roles around jobs, not status
The most reliable permission setup starts with responsibilities. “Admin” is a familiar label, but it does not tell you what the person should actually be able to do. Before changing your configuration, list the jobs on your server.
- Support staff: handle player questions and basic tickets.
- Moderators: manage disruptive behavior and routine enforcement.
- Event staff: access only the tools needed to run scheduled events.
- Developers: may need controlled access to diagnostics or development-only commands.
- Administrators: manage broad operations and sensitive configuration.
- Owners: retain the smallest group of truly unrestricted authority.
Then grant each role the minimum access needed to complete its job. This least-privilege approach is less glamorous than handing out an all-powerful group, but it limits damage from mistakes, compromised accounts, and role confusion.
It also makes promotions easier. Moving a trusted moderator into an administrator role should mean adding one group relationship, not hunting through dozens of player-specific lines.
A practical structure for a small or mid-sized server
A clean setup often uses a few layers. The names are yours to choose, but the design should be easy for the next staff member—or future you—to understand.
- Create a base staff group for harmless or routine staff tools.
- Create a moderator group that inherits the base staff group.
- Create an administrator group that inherits moderator access.
- Keep owner-only actions in a separate group rather than treating every administrator as an owner.
- Assign player identifiers to groups, instead of assigning command permissions directly to players.
For example, the relationship can be expressed conceptually as: owner inherits admin; admin inherits moderator; moderator inherits staff. Add permissions at the lowest appropriate level. If every role needs a tool, grant it to the shared base group. If only administrators need it, keep it on the administrator group.
When organizing a larger configuration, add short comments around each role and resource section. A readable config is a security feature. Six months later, “why does this identifier have this permission?” should not become a detective story.
Command permissions and script permissions are not automatically the same
One common mistake is assuming that allowing a command grants access to every feature inside the resource that owns it. That is not necessarily true.
A resource might check a custom ACE object before opening an administrative menu, while its command uses a different check. Another resource may use an entirely separate permission system, a framework role, database-backed jobs, or its own configuration. FiveM ACE is powerful, but it cannot magically standardize every third-party script.
Before adding a permission rule, check the resource’s original documentation or source where its license permits. Look for the exact ACE object it checks, whether it expects an identifier or group, and whether it has additional configuration requirements. If documentation is unclear, test in a controlled environment instead of granting broad access on the live server.
Why broad wildcards can become a problem
Broad permission patterns can be tempting, especially when a new staff member says a tool is not working. But a rule that grants a wide command family may also grant commands added later by a resource update. That is convenient until it is not.
Prefer explicit permission objects for sensitive actions, especially those that can alter player inventories, spawn assets, change server state, execute administrative actions, or expose internal data. A few extra lines are usually cheaper than untangling an accidental permission escalation.
Denies can be useful when you need to carve out an exception, but they should not be your primary design tool. A role model that depends on a maze of allows and denies is difficult to reason about. Start narrow, then add only what a role demonstrably needs.
Test permissions like you test a resource update
Permissions deserve a test plan because a config that loads is not automatically a config that behaves correctly. Use a non-owner test account for each role when possible. Testing with an owner account can hide missing permissions because the account already has broad access.
- Confirm that a role can perform the actions it is meant to perform.
- Confirm that the same role cannot access owner-only or developer-only actions.
- Check both commands and any menus or UI elements the resource provides.
- Test after a resource update, framework change, or staff-management change.
- Keep a backup of the last known-good configuration before editing access rules.
If a permission change has no effect, slow down before adding more broad allowances. Verify the exact object name, confirm that the player identifier is the one you expect, check that the relevant resource has started, and review the server console for configuration errors. The issue may be a typo, an identifier mismatch, or a resource that does not use ACE at all.
Use official documentation as the source of truth
FiveM evolves, and individual resources implement permissions differently. For command syntax and current server configuration behavior, start with the official FiveM server command documentation. It is more trustworthy than a pasted config snippet with no context.
Also remember that a framework permission, a Discord role, a txAdmin setting, and an ACE group can be related in your overall operations—but they are not automatically interchangeable. Document which system controls which capability. That one habit prevents a lot of “I gave them the role; why can’t they use the command?” support tickets.
Keep an access review on your server checklist
Permissions are not a set-and-forget task. Remove access when staff leave, review temporary exceptions, and revisit roles as your server adds resources. If a group has grown into a junk drawer of unrelated privileges, split it into clearer roles before the next major update.
For GTA VI context, this information is speculative and might not accurately represent current or future events: no assumption should be made that GTA VI, any future multiplayer platform, or future modding tools will use FiveM’s current ACE model. The useful lesson is broader than one platform—build clear roles, use documented permission checks, and avoid granting more access than a job requires.
A well-organized permission system will not make roleplay better by itself, but it gives your team room to focus on players instead of preventable access problems. When you are ready to expand your server toolkit, check out the available mod downloads or create a free account to join the SixMods community and share what is working for your server.
Responses