Skip to content

Oxide permissions 101

Updated June 14, 2026
Rust
Oxide Permissions 101 | GameServerKings KB

Oxide Permissions 101

Once your 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 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.

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

(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. Create a group, set its rank (higher rank wins when groups conflict), and grant the perks:

Console
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:

Console
oxide.usergroup add 76561197960287930 vip

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

Console
oxide.usergroup remove 76561197960287930 vip

Creating an Admin Group

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:

Console
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:

Console
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:

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

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

Console
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:

Console
oxide.show groups

Show every permission granted to a specific group:

Console
oxide.show group vip

Show every group and permission a specific user has:

Console
oxide.show user 76561197960287930

Show every player in a group:

Console
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):

Console
oxide.show permissions kits

Wildcards

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

Console
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

The GSK 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.
Made with 💜 by GameServerKings