Rust Oxide permissions 101

Once your Rust server has more than two or three plugins, granting access per player becomes painful. The Oxide and Carbon permission systems are built around groups: bundles of permissions you assign to a tier of players, then add players to the group.

This guide shows how to set up a clean three-tier structure (default, VIP, admin), assign permissions, and audit who has what.

How Rust Server Permissions Work

Every plugin defines a set of permission strings, usually shaped like pluginname.feature. Examples:

• kits.kit.starter (access to the "starter" kit)
• teleportation.tp (use /tpr)
• removertool.normal (remove your own builds)
• adminradar.allowed (use the admin radar)

A permission can be granted to:

• A specific user (by SteamID64 or display name)
• A group (then anyone in that group inherits it)

Group-based is almost always what you want.

The Default Group

Every player who connects is automatically added to a built-in group called default. Grant the baseline permissions every player should have to this group.

> oxide.grant group default kits.kit.starter
> oxide.grant group default teleportation.tp
> oxide.grant group default removertool.normal

Carbon uses c.grant

Use c.grant ... on Carbon. The Oxide syntax also works on Carbon as an alias.

Creating a VIP Group

Most servers monetize through a VIP tier. What Facepunch's guidelines actually let that tier include — and the DLC rules that get servers delisted for getting it wrong — is set out in Rust Server Monetisation. Create a group, set its rank (higher rank wins when groups conflict), and grant the perks:

> oxide.group add vip "VIP" 10
> oxide.grant group vip kits.kit.vip
> oxide.grant group vip backpacks.size.12
> oxide.grant group vip signartist.url
> oxide.grant group vip serverrewards.bonus

The 10 at the end of the add command is the group's rank. The default group has rank 0.

Add a player to VIP:

> oxide.usergroup add 76561197960287930 vip

To remove them (e.g., subscription lapsed):

> oxide.usergroup remove 76561197960287930 vip

Creating an Admin Group

ownerid gives full RCON and console access

Admins should not be ownerid (that gives them full RCON and console access, including ban and unban).

Instead, create a moderation group with the permissions they actually need — our moderation playbook sets out which powers each staff tier should and should not hold:

> oxide.group add admin "Admin" 100
> oxide.grant group admin adminradar.allowed
> oxide.grant group admin teleportation.admin
> oxide.grant group admin removertool.target
> oxide.grant group admin kits.admin
> oxide.grant group admin betterchat.admin

Then assign your trusted staff:

> oxide.usergroup add 76561197960287930 admin

You can also use Rust's built-in moderatorid for in-game moderation tools (noclip, godmode, kick, ban). That is separate from Oxide permissions and is set in users.cfg or via the console:

> moderatorid 76561197960287930 "StaffName" "trusted staff"
> server.writecfg

A common setup: staff are in the Oxide admin group AND added with moderatorid. Reserve ownerid for the actual server owner.

Granting to Individuals with oxide.grant

When you want one player to have a single perk without joining a group:

> oxide.grant user 76561197960287930 signartist.url

You can pass a player's name instead of SteamID if they are online. SteamID is safer because names change.

Auditing What's Granted

Show every group:

> oxide.show groups

Show every permission granted to a specific group:

> oxide.show group vip

Show every group and permission a specific user has:

> oxide.show user 76561197960287930

Show every player in a group:

> oxide.show members vip

Show every permission a plugin has defined (useful when you install a new plugin and want to see what perms exist — StackSizeController, for instance, registers one node per command, and every one of its commands stays silent until that node is granted):

> oxide.show permissions kits

Wildcards

You can grant all permissions under a plugin namespace with *:

> oxide.grant group admin kits.*
> oxide.grant group admin teleportation.*

Use sparingly. It is often clearer to grant explicit permissions so future readers of your config can see what each group can do.

Backing Up Permissions

The permission database lives at oxide/data/oxide.users.data and oxide/data/oxide.groups.data (Carbon: carbon/data/). Back these up before:

• Wipes (if you intend to preserve VIP across wipes)
• Plugin updates that change permission names
• Migrating from Oxide to Carbon

A panel backup before a wipe captures everything

The panel Backups tab snapshots the entire server volume, so a panel backup before a wipe captures everything.

Restoring VIP Across Wipes

A common request is "I paid for VIP, will I keep it after the next wipe?" The answer depends on whether you wipe the permission data:

• Map wipe only (default): Permissions persist. VIP players keep VIP automatically.
• Map + BP wipe (forced wipe, first Thursday): Same as above. Permissions persist unless you delete them.
• Full wipe (delete oxide/data/): VIP is lost.

Most servers do not wipe permissions during a forced wipe. If you do, you will need to re-grant VIP from your payment records.

Common Pitfalls

• Granting to a user that does not exist yet: Oxide accepts the grant but the player has to log in once for it to take effect. SteamID grants work even before the first login.
• Case sensitivity: Permission strings are case-sensitive in some places. Stick with all lowercase.
• Conflicts: If a player is in two groups with conflicting permissions, the higher-rank group wins. That is why we used 100 for admin.
• Plugin updates rename a permission: When this happens, the old permission lingers in the data file but does nothing. Audit with oxide.show user ... after major plugin updates.

Oxide Permission Manager Commands

Every Oxide command has three names that behave identically: the full oxide. form, the short o. form, and — for permission commands — a perm. form. Use whichever you prefer. Type them in the Console tab of your hosted Rust server, or in-game chat with a / in front.

Grant and revoke both take exactly three arguments, in this order:

> oxide.grant <user|group> <name or steam id> <permission>
> oxide.revoke <user|group> <name or steam id> <permission>

If you pass fewer than three, Oxide prints the usage line back at you rather than doing anything.

The same naming covers plugin management:

Carbon accepts the same o. commands, so everything here works on a Carbon server too.

What to Read Next

• Popular Plugins lists the permission nodes for each plugin in one place.
• How to configure the StackSizeController plugin is a worked example of granting a plugin's whole node set to a group.
• How to Use External RCON Tools lets you manage permissions from outside the panel.

Made with 💜 by GameServerKings