How to set uMod plugin permission on your Rust server

Installing a plugin on your Rust server is only half the job. Most Oxide and Carbon plugins do nothing until you explicitly grant the right people permission to use them. If you have ever dropped a plugin into oxide/plugins/, reloaded it, and then watched it do absolutely nothing in-game, the missing piece is almost always permissions. This guide walks through the entire permission system from the ground up: the two built-in groups, the exact oxide.grant and oxide.revoke syntax, how groups and inheritance work, the pluginname.permission node format, and why every one of these commands works identically whether you run Oxide/uMod or Carbon.

How the Oxide permission system works

Oxide (also known as uMod) is the long-established Rust modding framework, with the largest plugin library available — over 1,400 plugins on uMod alone. Its permission system is built on two simple concepts: permissions and groups. A permission is a single string that unlocks one capability of a plugin. A group is a named bucket of users that can hold a bundle of permissions. You can assign permissions directly to an individual player, or to a group that the player belongs to — and in practice, granting to a group is almost always the cleaner approach.

When you install Oxide, it automatically creates two default groups: admin and default. Every player who connects is a member of default, and any player with an auth level (an owner or moderator) is automatically placed in admin. This is why so many plugins “just work” for admins out of the box but appear broken for regular players — the plugin author granted its core permissions to the admin group, and the default group has nothing. Your job as a server owner is to decide which capabilities the default group (everyone) gets, and which you reserve for special groups like VIPs, supporters, or moderators.

The pluginname.permission node format

Every permission in Oxide follows the same format: pluginname.permission. The first part is the plugin’s registered name (lowercased), and the second part is the specific capability that the plugin’s author defined. So a plugin called CoolPlugin might register coolplugin.use for general access, while the Vanish plugin registers vanish.allow for the players allowed to go invisible. There is no universal list — each plugin documents its own permission nodes, usually in its description page or config. The pattern, however, never changes:

coolplugin.use      # general access to CoolPlugin
vanish.allow        # allowed to use the Vanish plugin
removertool.normal  # example node: standard remove access
serverrewards.use   # example node: access the rewards store

To find a plugin’s exact nodes, read its documentation first, then verify in-game with the inspection commands covered later in this guide (oxide.show perms and oxide.show perm ). Never assume a node name — a typo in a permission string fails silently, and that is the single most common reason a “broken” plugin is really just a misspelled grant.

Granting and revoking permissions to a user

The most direct way to give a single player access to a plugin is to grant the permission to that user. Oxide accepts either the player’s name or their SteamID64 (the 17-digit number, for example 76561197854018763). The SteamID64 is always the safer choice because names change and can contain spaces or special characters that confuse the parser. You can read a connected player’s SteamID64 from the ID column of the status command.

# Grant a permission to a single user (by name OR SteamID64)
oxide.grant  user 76561197854018763 coolplugin.use
oxide.grant  user "PlayerName" coolplugin.use

# Revoke that permission from the user
oxide.revoke user 76561197854018763 coolplugin.use
oxide.revoke user "PlayerName" coolplugin.use

Direct user grants are perfect for one-off cases — handing a single content creator access to a special command, or testing a permission before you roll it out. But they get unmanageable fast. If you grant ten permissions to twenty VIPs individually, you now have two hundred grants to track, and revoking VIP status from one player means hunting down ten separate commands. That is exactly the problem groups solve.

Working with groups

Groups let you define a permission set once and then move players in and out of it. The workflow is: create a group, grant the group its permissions, then add users to the group. When a player joins the group they inherit every permission the group holds; remove them and the access is gone instantly — no need to revoke each node one by one.

Creating and deleting groups

# Create a new group
oxide.group add supporters

# Remove a group entirely
oxide.group remove supporters

# Set a display title and a rank number for the group
oxide.group set supporters "[Server Supporters]" 1

The oxide.group set command assigns a human-readable title (often used by chat plugins to show a tag next to a player’s name) and a numeric rank that some plugins use to order groups. The admin and default groups already exist and should not be deleted — they are part of the framework’s core behavior.

Granting permissions to a group

Granting and revoking for a group uses the same oxide.grant / oxide.revoke verbs you saw for users — you just swap user for group:

# Grant a permission to a whole group
oxide.grant  group supporters coolplugin.use
oxide.grant  group admin      coolplugin.use

# Revoke a permission from a group
oxide.revoke group admin      coolplugin.use

A very common pattern is granting a capability to the default group so that every player on your server can use it — for example, letting everyone use a teleport-to-home plugin or a player-side remove tool. Reserve more powerful nodes for purpose-built groups, and keep truly destructive admin tools on the admin group only.

Adding and removing users from groups

Once a group holds the permissions you want, you move players in and out with oxide.usergroup. As with grants, you can reference a player by name or SteamID64.

# Add a user to a group
oxide.usergroup add    76561197854018763 supporters
oxide.usergroup add    "PlayerName"      supporters

# Remove a user from a group
oxide.usergroup remove 76561197854018763 supporters
oxide.usergroup remove "PlayerName"      supporters

This is where the group model pays off. Selling a VIP rank? One oxide.usergroup add command grants the buyer everything the VIP group offers. Refund or expiry? One oxide.usergroup remove and they lose it all. Most donation and store plugins automate exactly these two commands behind the scenes.

Group inheritance (parents)

Oxide supports group inheritance through parents. A child group inherits every permission its parent holds, on top of its own. This lets you build tiered ranks without re-granting shared permissions at every level.

# Make tier_2 inherit everything tier_1 has
oxide.group parent tier_2 tier_1

Picture a three-tier donor system. You grant baseline perks to tier_1, then set tier_2‘s parent to tier_1 and add only the extra perks; tier_2 members automatically get the baseline plus their own. Set tier_3‘s parent to tier_2 and it stacks again. When you later add a new perk for everyone, you grant it once at tier_1 and it cascades upward through the chain.

Inspecting permissions and groups

You cannot manage what you cannot see. Oxide’s oxide.show family of commands lets you audit exactly who has what. Use these constantly — they are how you confirm a grant actually landed and how you debug a “permission isn’t working” report.

oxide.show groups               # list every group
oxide.show group admin          # show the members of a group
oxide.show user       # show a user's groups + permissions
oxide.show perms     # show all permissions held by a group
oxide.show perm coolplugin.use   # show who/what has a specific permission

A reliable troubleshooting routine: run oxide.show user "PlayerName" to see the player’s groups and direct permissions, then oxide.show perms on each of their groups to confirm the node is actually present and spelled correctly. Nine times out of ten the issue is a misspelled node, a player who isn’t in the group they should be, or a plugin that didn’t reload after a config change.

Command reference table

Command	What it does
oxide.grant user	Grant a permission to one player
oxide.revoke user	Revoke a permission from one player
oxide.grant group	Grant a permission to a whole group
oxide.revoke group	Revoke a permission from a group
oxide.group add	Create a new group
oxide.group remove	Delete a group
oxide.group set "