Grant a specific server permission and prove it works

An ACE grants or denies an object to a principal. A principal can represent a player identifier or a group. add_principal establishes inheritance; it does not automatically grant every permission to a name such as group.admin.

Start without broad grants, allow the exact operation you need, and test both permitted and unpermitted accounts. Do not copy a blanket command allow rule when the goal is to allow one command.

ACE (Access Control Entries)

Create resources/[local]/doc_permissions/fxmanifest.lua:


fx_version 'cerulean'
game 'gta5'
server_script 'server.lua'

Create server.lua:


RegisterCommand('docstatus', function(playerId)
    print(('[doc_permissions] Status requested by %s; resource is running.'):format(playerId))
end, true) -- Restricted server command: checks command.docstatus for players.

The command prints to the server console, not the player’s chat. It is intentionally harmless so you can test the permission system before protecting consequential operations.

Identifiers

Use an identifier obtained from the server’s trusted administration tools. A session number such as 12, a display name, or a client-submitted identity is not a stable permission principal.

Place these lines in server.cfg, replacing the placeholder with the real account identifier:


add_ace group.docoperator command.docstatus allow
add_principal identifier.license:REPLACE_WITH_YOUR_LICENSE group.docoperator
ensure doc_permissions

The identifier. prefix belongs to the ACE principal syntax; the underlying identifier is license:.... Do not publish your real account identifiers in documentation or grant access to an unverified value supplied by another player.

Test effective access

After creating the resource, run refresh and ensure doc_permissions in the server console. Then inspect the group permission:


test_ace group.docoperator command.docstatus
test_ace group.docoperator command.restart

The first should be allowed. The second should not be allowed unless another rule already grants it. Test the actual identifier principal too:


test_ace identifier.license:REPLACE_WITH_YOUR_LICENSE command.docstatus

Finally, test as two players: one in the group and one outside it. Do not use a successful server-console execution as proof that a player’s permission is correct; console execution is a different context. Check the server log after the permitted player invokes docstatus from F8.

Safe Defaults

Unmatched permission checks do not need a blanket deny rule to be refused. Avoid adding broad inherited denies such as add_ace group.everyone command deny as a universal starter configuration. An applicable explicit deny can prevent a later, narrower allow from doing what you expected.

Likewise, add_ace group.admin resource allow is not a generic grant of all resource capabilities. Custom object names only matter when the relevant code checks them.

Symptom	Inspect
Permitted player is denied	Exact command name, principal identifier, inherited deny rules, and whether configuration was applied
Everyone can use the command	Whether the server’s `RegisterCommand` has `true`; whether another group grants the object
`test_ace` works for a group but not a player	The player’s actual identifier and `add_principal` inheritance
txAdmin access differs from an in-game command	txAdmin’s administrator permissions and FXServer ACE rules are distinct systems
A hidden client button is bypassed	Move authorization into the server handler; hiding UI is not permission enforcement

Revoke access without widening another rule

In the server console, remove the membership or the specific grant:


remove_principal identifier.license:REPLACE_WITH_YOUR_LICENSE group.docoperator
remove_ace group.docoperator command.docstatus allow

Update the persistent configuration as well, otherwise a restart may restore the removed rule. Run test_ace again; inherited permissions from other groups may still allow the action.

For a custom network event, call IsPlayerAceAllowed with a purpose-specific object as shown in secure events. For connection approval, use connection deferrals. For configuration persistence, see resource storage. The official server-command reference defines the ACE administration commands, and the Cfx.re ACL explanation explains principals and access checks.