---
title: "Rust Oxide permissions 101"
description: "Master Oxide permissions, manage default and custom group behavior, implement wildcard targets, and audit active server access."
url: "https://www.gameserverkings.com/knowledge-base/rust/oxide-permissions-101/"
category: "Rust"
category_url: "https://www.gameserverkings.com/knowledge-base/rust/"
published: "2026-03-15T21:25:01.463Z"
updated: "2026-08-19T10:49:52.160Z"
source_format: "markdown"
site: "GameServerKings"
---

# 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
```

> [!NOTE] 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](/knowledge-base/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

> [!WARNING] `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](/blog/game-server-moderation-tips/) 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](/knowledge-base/rust/add-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

> [!TIP] 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](/knowledge-base/rust/wipe-day-guide/) 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](/games/rust-server-hosting/), or in-game chat with a `/` in front.

| Command | Aliases | What it does |
| --- | --- | --- |
| `oxide.grant` | `o.grant`, `perm.grant` | Give a permission to a user or group |
| `oxide.revoke` | `o.revoke`, `perm.revoke` | Take a permission away again |
| `oxide.group` | `o.group`, `perm.group` | Create, delete or reparent a group |
| `oxide.usergroup` | `o.usergroup`, `perm.usergroup` | Add or remove a player from a group |
| `oxide.show` | `o.show`, `perm.show` | Show what a user, group or permission holds |

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:

| Command | Aliases | What it does |
| --- | --- | --- |
| `oxide.plugins` | `o.plugins`, `plugins` | List loaded plugins |
| `oxide.load` | `o.load`, `plugin.load` | Load a plugin |
| `oxide.reload` | `o.reload`, `plugin.reload` | Reload a plugin after editing its config |
| `oxide.unload` | `o.unload`, `plugin.unload` | Unload a plugin |
| `oxide.save` | `o.save` | Force a save of permission and plugin data |
| `oxide.version` | `o.version` | Print the installed Oxide version |

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

## What to Read Next

- [Popular Plugins](/knowledge-base/rust/popular-plugins/) lists the permission nodes for each plugin in one place.
- [How to configure the StackSizeController plugin](/knowledge-base/rust/add-stacksizecontroller/) is a worked example of granting a plugin's whole node set to a group.
- [How to Use External RCON Tools](/knowledge-base/rust/how-to-use-external-rcon-tools/) lets you manage permissions from outside the panel.

---

Made with 💜 by GameServerKings