Skip to content

Servers

Minecraft plugin permissions explained for server owners

How permission nodes work in Bukkit plugins: defaults, op, groups, wildcard nodes and how to grant or remove them with a permissions plugin.

· Updated · 3 min read
Cover image: Minecraft plugin permissions explained for server owners

Permissions decide who may use what on your server. Every command or feature in a plugin is guarded by a permission node, a short text like homes.use. Understanding them makes setting up ranks much easier.

What a permission node is

A node is a name written with dots, from general to specific, for example kits.vip. The plugin asks the server "does this player have kits.vip?" and acts on the answer. The plugin author decides the names, and a good plugin lists them in its documentation and in plugin.yml.

Defaults

Each permission has a default that applies until you change it: true (everyone), false (nobody), op (operators only) or not op. Everyday player features usually default to true, admin features to op.

Granting and removing with a permissions plugin

The built-in system is basic. Most servers use a permissions plugin such as LuckPerms to create groups (default, vip, moderator) and give each group nodes. A typical setup grants kits.starter to everyone and kits.vip only to the vip group.

/lp group vip permission set kits.vip true
/lp group default permission set kits.starter true
/lp user Steve parent set vip

Wildcards

A node ending in .* grants everything under it, so kits.* covers kits.starter and kits.vip. Many plugins support this, but only because their author declared child permissions. Do not give * to anyone you do not fully trust, because it means every permission.

Checking what a player has

LuckPerms has a verbose mode and a check command that show exactly which node was asked for and what the answer was. When a command says "You do not have permission", that tells you which node to grant.

Designing permissions for your own plugin

  • One node per action, named plugin.action.
  • Separate "use" from "use on others" and from "bypass the cooldown".
  • Put the admin nodes on op by default.
  • Say in your description what each should be, so the generated plugin declares them in plugin.yml.

A small example of permission design

Imagine a kits plugin with two kits. You define the nodes kits.starter and kits.vip, give kits.starter to the default group and kits.vip to the vip group. You also add kits.bypass.cooldown for staff. Each node means one thing, and you can read the whole setup in a minute.

permissions:
  kits.starter:
    default: true
  kits.vip:
    default: false
  kits.bypass.cooldown:
    default: op

Common mistakes

  • Giving everyone op instead of a permission. Op bypasses every check and is hard to undo.
  • Using one node for many things, so you cannot allow one action without the rest.
  • Forgetting that negative permissions beat positive ones in many setups.
  • Not testing with an account that has no permissions at all.

Frequently asked questions

Do I need a permissions plugin?

For more than a handful of ranks, yes. The built-in system only knows op and not op.

Can a player have a permission only in one world?

Permissions plugins such as LuckPerms support contexts for that. The plugin itself does not need to know.

Are permissions case sensitive?

Treat them as case sensitive and write them in lowercase everywhere.

Written by

PluginForge Team

We build PluginForge, the AI Minecraft plugin creator. The guides come from what we see when plugins are generated, compiled and installed on Paper and Spigot servers.

More guides

RSS feed · All guides