Skip to main content

Test FiveM ACE permissions without granting full command access

FiveM's ACE system answers whether a principal may use an object. A principal can be an identifier, group or resource; an object is a permission name checked by a command or script. Inheritance connects principals. This is separate from txAdmin's staff permissions and may also be separate from your framework's job or group system.

Start with the resource's documented object

Find the exact ACE name the resource checks. A script checking examplemenu.open will not necessarily use a guessed group called moderator. Likewise, a command only uses the built-in restricted-command check when registered that way; ACE configuration cannot secure an event the script exposes without checking permission. Ask the author when their access model is unclear.

Back up your permission configuration and included files before editing. If a framework stores access assignments in its database, export the matching database too. Work with a test account, and record any temporary console commands so you can undo them. Console changes should not be mistaken for durable configuration.

Use a harmless scoped test

The following uses an invented permission object solely to demonstrate ACL behaviour. Run it in the FXServer console as the owner. It does not grant an actual administrative command:

add_ace group.help_demo cloudexa.helpcheck allow
test_ace group.help_demo cloudexa.helpcheck
remove_ace group.help_demo cloudexa.helpcheck allow
test_ace group.help_demo cloudexa.helpcheck

The first test should show permission; the second should not unless another rule supplies it. If the result differs, inspect inheritance and existing rules before adding more grants. This proves the ACL mechanism, not that any installed script uses the invented object.

Connect a real user carefully

For a real permission, use the player's verified stable identifier and the author's exact object. A conceptual assignment looks like this; replace the identifier placeholder privately before use:

add_principal identifier.license:REPLACE_WITH_VERIFIED_ID group.example_staff
add_ace group.example_staff examplemenu.open allow

This grants only the named object's access, subject to other applicable rules. Do not copy an identifier from a public screenshot or assume the player's current numeric server ID is permanent. Test the intended object against that principal with test_ace, then test the actual feature with the player. Keep screenshots and shared logs free of full player identifiers.

Understand inheritance before widening access

Adding a principal to a group can inherit everything that group already allows. A broad parent can silently give more power than the two lines you just added suggest. Explicit deny rules can also explain a refusal. Avoid granting the whole command namespace, owner groups or permission-management commands simply to silence one error.

Persist the smallest working rules in the intended configuration file and verify them after a planned restart. Remove a temporary relationship with remove_principal using the same child and parent arguments. Removing one relationship does not remove permissions inherited through another path. Retest both the desired feature and an unrelated restricted feature, then document who has access and why.

Further reading

Looking for another game? Browse game server setup and troubleshooting guides.

No comments to display