uMod/Oxide Permissions System
Many of the special features added by plugins in the game Rust will not automatically work for players or groups, unless special "permissions" are given to use them.
You do this by connecting to the server with an RCON tool, and giving special commands to the server, which are used by an entire permissions system that is built into the uMod/Oxide plugin framework. When a player or group has the correct permissions tags added in this permissions system, they will be allowed to use the special abilities or features of the plugin.
Not all plugins require these permissions tags. Some plugins work automatically for all players, as soon as they are added to the server. But if any plugin adds special powers you don't want everyone to have (turn invisible, walk through walls, etc), then you need to use the permissions system and the permissions tags to control who can and cannot use those plugin abilities.
An Important Thing About Permissions Systems
Like almost all permissions systems, its automatic answer to "can someone use this ability?" is "NO!!!!!!". A really big loud "NO!". The automatic default answer of permissions systems is to say NO. All the time, every time, to any request to use anything. Forever. Unless you have added a "Yes" answer to their permissions, which allows them to use it.
The vast majority of plugins will not work at all until you add permissions for them, either to each individual player or to a whole group (that the player belongs to). Until you add permissions, every time you try to use a command, the uMod/Oxide permissions system will just keep saying "nope, nada, uh uh, ain't gettin' past me, not happenin', not on my watch!". That is it's job, it's designed to say NO.
Does a Plugin Have Permissions?
When you view a plugin on uMod, if there is a section in the description that begins with "# Permissions", then yes it does. Underneath that will be listed the permissions and what they do.
Some are really simple. The "Whitelist" plugin by Wulf has only one, whitelist.allow. Add that, and you're allowed to join a server. Without it, you can't join. Simple.
Some are more complex, a lot more complex. Below are the permissions for the "Vanish" plugin.
This one is a little trickier!
The basic vanish.use is needed to even use the invisibility, without that permissions, you can't even turn invisible. But then the other settings change how it works.
If you don't have vanish.damage.players, you cannot hurt anyone while you are invisible. Another controls if you can damage a building, or an animal while invisible. There are other settings to make your weapons invisible too, to make you invulnerable while invisible, etc, etc. And all of this is just to control how a single plugin works.
How to Add Permissions
Before you can add permissions, there's a few things you need to set up beforehand. We have guides in our knowledgebase on most of this already, so rather then repeat it all, there are links below for each step.
You Need an RCON Tool
Without an RCON, your Rust server is like a car with no steering wheel. Or a brake pedal, gas pedal, speedometer, gas gauge, or even knobs on the radio. You pretty much can't do anything on your Rust server, without some kind of RCON program. The RCON is how you send instructions to the server (and Oxide too) on what to do, and see feedback on what it's doing behind the scenes.
Our guide on how to install and setup "RustAdmin", which is one of many different RCON tools, is here: https://nodecraft.com/support/games/rust/setting-up-the-rust-admin-rcon-tool
Become an Admin First
We have a guide on how to set yourself as an admin on your Rust server here: https://nodecraft.com/support/games/rust/become-admin-on-a-nodecraft-rust-server
Groups! Groups! Groups!
The more efficient way to add permissions, is to create a group first, and then assign permissions to the entire group. Then you set which players are in that group.
This is more work in the beginning, but pays off BIG TIME in the long run. When you want to make changes, you just edit the permissions for the whole group, and it changes on all the players in that group. As opposed to having to go into each separate player and add, delete, or change the permissions, and then the next player, and the next player.
Additionally, using groups is a good way to not forget you left a permissions turned by accident. As an example...
Let's say, you passed a permission out like candy one day, but then later on you decided it was too powerful and removed it from everyone's list. Except, you forgot bob. Bob hasn't played in a long time. Bob was kind of a... well, you know what. You were glad when Bob stopped playing.
But out of the blue, Bob does join the server, realizes they still have this superpower (like turn invisible), and goes on a rampage across the server. Oof. Big mess. Many unhappy players. Much griping is heard unto the admins (even less time playing, while you clean up the mess). Using groups are a great way to make sure you don't accidentally leave an ability turned on. Change it in one place, change it for everyone.
uMod/Oxide Commands
In the following sections are the commands for the uMod/Oxide permissions system. Theses commands are universal to uMod by the way, so they will work in any other game using uMod, not just Rust.
In the syntax for many commands, you will see multiple words enclosed by < and >. That means you have replace it with one of the terms between the < and >.
The < and > are not typed as part of the command.
In the commands you can also use a username or a Steam64ID number. We prefer to use the Steam64ID number, but they're not exactly user friendly, and if you have many players it can be hard to remember which number is which player.
For example the command:
oxide.grant <user or group> / <playername or steam64ID> <permission>Means that you can use "user" or "group". They are just variables for the basic command oxide.grant, so the same command can be
oxide.grant user genericplayername <permission>or
oxide.grant group genericgroupname <permission>Examples:
oxide.grant user playername vanish.use
oxide.grant user playername whitelist.allowOn all the following commands, the word "oxide" can also be shortened to just the letter "o". So oxide.grant can be replaced with o.grant.
Adding and Removing Permissions for Players
oxide.grant
This command will add a permission to a player.
oxide.grant user <playername or steam64ID> <permission>oxide.revoke
This command will remove a permission from a player.
oxide.revoke user <playername or steam64ID> <permission>The Permissions Wildcard
If you replace the permission with just an asterisk (*), it gives that player access to ALL permissions installed on the server. Use that carefully; that can get scary.
oxide.grant user <playername> *Adding and Removing Permissions for Groups
These are basically the same command from the player section, but "user" is replaced with "group"
oxide.grant
This command will add a permission to a group.
oxide.grant group <groupname> <permission>oxide.revoke
This command will remove a permission from a group.
oxide.revoke group <groupname> <permission>The Permissions Wildcard
Just like with a single player, if you replace the permission with just an asterisk (*), it gives that entire group access to ALL permissions installed on the server.
In the case of an entire group, this is even scarier then a single player with the wildcard.
oxide.grant group <groupname> *Listing Permissions for Players and Groups
oxide.show player
Shows all the permissions granted to a specific player
oxide.show player <playername or Steam64ID>oxide.show perm
This will show all players or groups which have been granted a specific permission.
oxide.show perm <permission>Creating and Removing Groups
uMod/Oxide has two default groups "user" and "admin", any other groups you wish to have will have to be created.
oxide.group add
This command will create a whole new group, with whatever text you use for <group name>
oxide.group add <group name>oxide.group remove
This command will remove an existing group
oxide.group remove <group name>oxide.group parent
This command sets the parent and/or child group for a group. This is useful for inheriting default permissions from one group to another, which is a faster and easier way to set up permissions for multiple groups. All the permissions of a "parent" group will be automatically be given to the "child" group, so you can quickly stack up groups, and only add new permissions to each new one. This greatly reduces the amount of work required to create groups.
oxide.group parent <parentgroup> <childgroup>oxide.group set
This creates a short description for a group, which can be used for things like chat titles
oxide.group set <group name> "[sample text]"Only replace the sample text portion. The "[ and ]" are part of the command.
Adding and Removing Players from Groups
oxide.usergroup add
This command will add a player to a specific group
oxide.usergroup add <playername or Steam64ID> <group name>oxide.usergroup remove
This command will remove a player from a group
oxide.usergroup remove <playername or steam64ID> <group name>