Permissions on a Rust server: oxide.grant, groups and rights

Most plugins do nothing until you grant a permission to a player or a group. This guide explains how the permission system in Oxide and Carbon works, how to grant rights to a single player and to a whole group, how to set up VIP and moderator groups and how to fix the most common errors.

How permissions work#

• A permission is a string in the form plugin.action, for example kits.admin or nteleportation.home. A plugin registers it when it loads. The list of permissions is usually on the plugin's page.
• You grant permissions to a user (a specific player) or to a group. A player has the sum of their own permissions and the permissions of all their groups.
• A group can have a parent. It then inherits all permissions of the parent group. That way you don't have to grant the same rights several times.
• Default groups:
  • default – the framework automatically adds every player who connects.
  • admin – the framework automatically adds players with the owner level (ownerid).
  • moderator – Carbon only, automatically for players with the moderator level (moderatorid).
• Permissions only add up. There's no “deny”: if a group has a permission, every member has it, even if you revoked it from them directly.
• Permission and group names are case-insensitive.

Plugin permissions are not the same as the game's admin rights. The owner or moderator level (ownerid, moderatorid) gives access to Rust's own commands (teleport, noclip, ban…). Plugin permissions only control plugin features. So you can, for example, give a moderator invisibility from the Vanish plugin without giving them all of the game's admin commands.

Oxide stores users and groups in the files oxide/data/oxide.users.data and oxide/data/oxide.groups.data. Back them up and never delete them (you'd lose all granted rights).

Where to enter commands#

• Server console (on a game host, the Console tab) – the recommended place; commands always work here.
• RCON (RustAdmin, web console) – the same as the server console, just remote.
• The in-game F1 console – if you're an owner on the server (ownerid).

Type commands without a slash. Put names with spaces in quotes: "Jan Novák".

Steam ID instead of a name#

Identify players by their Steam ID64 (a 17-⁠digit number starting with 7656119). A name can change and two players can have similar names; the ID is unique and never changes. Oxide and Carbon also accept the ID of a player who hasn't connected to the server yet. How to find the ID is described in Admin and RCON.

The examples use 76561198000000000 – replace it with the player's real ID.

Permissions for a single player#

Granting rights player by player is fine for exceptions. For several people with the same rights, use groups.

Groups#

Example: a vip group that inherits everything from default and can also use the VIP kit.

Listing and checking#

oxide.show perms (c.show perms) is the quickest way to find the exact name of a permission when you don't know it from the plugin's documentation.

Wildcards#

An asterisk * grants several permissions at once:

oxide.grant group admin nteleportation.*

• nteleportation.* – all permissions that start with nteleportation..
• A lone * – every permission of every plugin.

The same works in Carbon: c.grant group admin nteleportation.*.

Recommended group structure#

The permission names in the table match the plugins from the Recommended plugins article. In Oxide you create the moderator group yourself (oxide.group add moderator "Moderator" 2); in Carbon it already exists.

Setting up the chain of parents in Oxide:

oxide.group parent vip default
oxide.group parent moderator vip
oxide.group parent admin moderator

A moderator then has the rights of a player and a VIP, and an admin has the rights of everyone.

Example: complete setup of a new server#

A set of Oxide commands that builds the structure from the table above for the NTeleportation, Backpacks, Kits, Vanish, Admin Radar, BetterChat and Remover Tool plugins. Enter them in the server console one by one once all the plugins have loaded (otherwise the permissions don't exist). In Carbon, replace oxide. with c., and instead of creating the moderator group, only set its parent.

oxide.grant group default nteleportation.home
oxide.grant group default nteleportation.tpr
oxide.grant group default backpacks.use
oxide.grant group default backpacks.gui
oxide.grant group default removertool.normal

oxide.group add vip "VIP" 1
oxide.group parent vip default
oxide.grant group vip kits.vip
oxide.grant group vip nteleportation.vip
oxide.grant group vip backpacks.size.24

oxide.group add moderator "Moderator" 2
oxide.group parent moderator vip
oxide.grant group moderator vanish.allow
oxide.grant group moderator adminradar.allowed

oxide.group parent admin moderator
oxide.group set admin "Admin" 3
oxide.grant group admin kits.admin
oxide.grant group admin betterchat.admin
oxide.grant group admin removertool.admin
oxide.grant group admin backpacks.admin

• The first block gives basic features to all players (homes, teleport requests, a backpack, removing their own buildings).
• The vip block creates the group, links it to default and adds the VIP kit (you have to create a kit with the kits.vip permission first), VIP teleport limits and a 24-⁠slot backpack.
• The moderator block adds invisibility and the radar.
• The admin block links the existing admin group to moderators, gives it the highest rank (3; Oxide created it with rank 1) and adds management of kits, chat, removal and backpacks. In Carbon, you set the rank with c.group set admin rank 3.

Then add people: oxide.usergroup add <ID> vip or oxide.usergroup add <ID> moderator. Admins (owners) end up in the admin group automatically.

The admin group and ownerid#

• ownerid (level 2) is the game's admin rights. It's set in Rust itself, see Admin and RCON.

• The admin group is a framework permission group. The framework adds players with level 2 to it automatically when they connect.

• Oxide doesn't remove players from the admin group by itself. If you take away someone's ownerid (removeowner), they stay in the admin group and keep their plugin rights. Remove them manually:

  oxide.usergroup remove 76561198000000000 admin

• Carbon syncs the admin and moderator groups with the player's actual level the next time they connect.

The admin group doesn't automatically get all plugin permissions. Grant whatever it should have yourself.

Carbon command equivalents#

Replace <ID> with the Steam ID64, <PERM> with the permission name and <GROUP> with the group name, all without the angle brackets.

Verification#

1. Enter oxide.show user 76561198000000000 (Carbon: c.show user …) and check that the player is in the expected groups and has the expected permissions.
2. Ask the player to try a plugin command (for example /kit). Some plugins load permissions when the player connects – if the feature doesn't work right away, have the player reconnect.

Troubleshooting#

Permission 'kits.vip' doesn't exist#

In Carbon: Couldn't grant permission - permission does not exist. Nothing has registered the permission at that moment. Causes:

• The plugin didn't load. Check oxide.plugins (c.plugins).
• A typo in the name. List the exact name with oxide.show perms (c.show perms).
• For kits: a kit with this permission hasn't been saved yet.

Player 'Jan' not found#

In Carbon: Couldn't grant user permission - user not found, use full name or steam ID. No player with that name can be found, because they haven't connected yet or have a different name. Use the Steam ID64 (17 digits).

Multiple players were found, please specify: …#

More than one player matches the name you entered. Use the Steam ID64.

Group 'vip' doesn't exist#

Create the group first: oxide.group add vip. For parent, both groups have to exist.

You do not have permission to use the command 'oxide.grant'!#

You entered the command in the game and you're not an owner on the server (ownerid). A moderator (moderatorid) can't use permission commands in the game (unless they have the permission of the same name, for example oxide.grant, which we don't recommend giving to moderators). Enter the command in the server console or over RCON. In Carbon, c.grant, c.group and similar commands require the owner level.

The player has the permission, but the feature doesn't work#

• The plugin may only check permissions on connect – have the player disconnect and reconnect.
• The plugin has a separate permission for each feature. In NTeleportation, for example, nteleportation.home only gives homes; returning to the previous location (/tpb) also needs nteleportation.tpb. Check the plugin's documentation.
• Some plugins check the game's admin level instead of permissions. Then a permission isn't enough and the player needs ownerid or moderatorid.

I revoked a permission, but the player still has it#

They have it through a group. Enter oxide.show user <ID> and see which groups they're in. Revoke the permission from the group, or take the player out of the group.

A former admin still has plugin rights#

After removeowner, they stayed in the admin group in Oxide. Remove them: oxide.usergroup remove <ID> admin.

Further reading#

• Oxide: permissions (official documentation) (opens in a new window)
• Oxide: permission commands (opens in a new window)
• Carbon: command list (opens in a new window)