Permissions and LuckPerms, without the guesswork.

How permissions work

A permission is a string such as autorefill.use. A plugin registers each node with a default value, and the server checks the node when a player uses a feature or command. A permissions plugin sits between the player and the server and answers those checks.

There are three default values a plugin can register:

The FerNode plugins use true for player-facing features and op for reload commands. That is convenient on a private server and too loose on a public one, where you may not want every visitor to use tree felling or automatic refill.

The nodes you will use

A true default is not a promise. A permissions plugin can still return false for a specific player or group, and that answer wins. To block a node for a group, set it to false or use a negated node such as -treefeller.use.

Installing LuckPerms

1. Stop the server.
2. Download the Bukkit/Paper build of LuckPerms that matches your Minecraft version.
3. Place the JAR in plugins/ and start the server.
4. Check that LuckPerms enabled and that plugins/LuckPerms/ was created.

LuckPerms stores data in a local H2 database by default, which is fine for one server. A network with several servers should use a shared MySQL/MariaDB database so every server sees the same groups. Do not enable that until you have one server working.

Core LuckPerms commands

These can be run from the console without the leading slash:

/lp creategroup member
/lp creategroup staff
/lp group member permission set treefeller.use true
/lp group member permission set autorefill.use true
/lp group member permission set ferkungstacker.use true
/lp group staff parent add member
/lp group staff permission set autorefill.reload true
/lp group staff permission set ferkungstacker.reload true
/lp user Steve parent add member
/lp user Alex parent add staff

The default group already exists. New players join it unless you change their group. A common setup is to put basic features on default, extra features on a rank group, and staff commands on a staff group that inherits the lower groups.

A worked example

Say you want everyone to use AutoRefill and FerKunG Stacker, but only a donors group to use UltraTreeFeller, and only admins to reload plugins. Turn the plugin defaults off at the group level and grant explicitly:

/lp group default permission set autorefill.use true
/lp group default permission set ferkungstacker.use true
/lp group default permission set treefeller.use false

/lp creategroup donor
/lp group donor parent add default
/lp group donor permission set treefeller.use true

/lp creategroup admin
/lp group admin parent add donor
/lp group admin permission set autorefill.reload true
/lp group admin permission set ferkungstacker.reload true

Because donor inherits default, it gets the two enabled nodes and the tree felling node it adds. admin inherits everything and adds the reload commands. Each group only states what it changes.

Negation, wildcards and order

A node written with a leading dash, such as -treefeller.use, is a negation. It removes the permission even if another group grants it. Use negation sparingly: it is easy to create a rule nobody remembers, and it can make inheritance hard to reason about.

Wildcards expand to every node under a prefix. ferkungstacker.* covers both the use and reload nodes. Be careful with wildcards on staff groups: they are convenient and also broad. If a future plugin version adds a destructive node under the same prefix, the wildcard grants it automatically.

When two sources disagree, LuckPerms resolves by the most specific answer and by group weight. If a player has both true and false for the same node, the negative usually wins unless you have arranged the weights deliberately.

Checking what a player actually has

Do not guess. LuckPerms can tell you the result of a check:

/lp user Steve permission check treefeller.use
/lp verbose on

permission check answers for one node. /lp verbose on prints permission checks to your chat as they happen, which is useful when a plugin behaves as if a node is missing. Turn it off with /lp verbose off when you are done.

Changes apply immediately. LuckPerms does not require a server restart, and a global /reload is not the fix for a permission problem. If a change does not take effect, check that you edited the right user or group and that no negation is overriding it.

Common mistakes

1. Editing the plugin YAML instead of using LuckPerms. Changing default: in plugin.yml inside a JAR is not how you manage live permissions.
2. Granting * to staff. It grants every node from every plugin, including ones you have not reviewed.
3. Forgetting that default: true already grants the node. To restrict a feature you must set it to false, not just "not grant" it.
4. Using uppercase node names. Nodes are case-sensitive and conventionally lowercase.
5. Blaming the plugin for a permission result. Check the node with LuckPerms before editing configs.

The short version

Player-facing FerNode nodes default to true and reload nodes default to op. On a public server, set the ones you want to restrict to false and grant them through LuckPerms groups. Keep inheritance simple, avoid broad wildcards for staff, and verify with permission check instead of guessing.

Contexts, weights and tracks

A permission does not have to apply everywhere. LuckPerms supports contexts, which scope a node to a server, world or gamemode. This is useful when a feature should be allowed in a creative plot world but not in survival.

/lp user Steve permission set treefeller.use true world=world_creative
/lp group default permission set treefeller.use false world=world

The rule of thumb is to keep contexts few. Every extra context is another condition that has to be true, and a permission problem becomes much harder to read when five contexts are in play.

Groups can have a weight. When two groups grant or deny the same node, the higher weight usually wins. Set weights deliberately instead of relying on creation order:

/lp group member setweight 10
/lp group donor setweight 20
/lp group staff setweight 50

Tracks are ordered lists of groups used for promotions. A common track runs from member to donor to staff; promoting a player moves them along it without editing each group by hand.

The web editor

/lp editor prints a link to a web editor for the current data. It is easier for reviewing a large permission table than typing commands, but changes still apply to the server when you save. Treat the link as sensitive: anyone who has it can read and change permissions until it expires.