from HTYP, the free directory anyone can edit if they can prove to me that they're not a spambot
Jump to navigation Jump to search



See Minecraft/server/commands for syntax. "permissions" can also be typed "perms" or "perm". Usernames are apparently not case-sensitive.

From web docs:

/permissions reload - reload the configuration from disk.
/permissions check [player] - check if a player or the sender has a permission (any plugin).
  • It's not clear how this works. I just get a message saying "Player Console defaults [player] to true." or "Player Console sets [player] to true.", depending on what I put in for "[player]".
/permissions info - prints information on a specific permission.
/permissions dump [player] [page] - prints info about a player's (or the sender's) permissions.
  • Annoyingly, this does not work unless the player is connected. /perm group players is more useful in this respect.
/permissions group - list group-related commands.
/permissions group list - list all groups.
/permissions group players - list players in a group.
/permissions group setperm <[world:]node> [true|false] - set a permission on a group.
/permissions group unsetperm <[world:]node> - unset a permission on a group.
/permissions player - list player-related commands.
/permissions player groups - list groups a player is in.
/permissions player setgroup - set a player to be in only the given groups.
/permissions player addgroup - add a player to a group.
/permissions player removegroup - remove a player from a group.
/permissions player setperm <[world:]node> [true|false] - set a permission on a player.
/permissions player unsetperm <[world:]node> - unset a permission on a player.

How To

  • To determine what permissions a user actually has (as opposed to what you think they have from looking at config.yml):
    • If the user is logged in: /perm dump [player] lists all permissions the player actually has
    • If the user is not logged in: /perm player groups to find out what permissions groups they're in; no apparent way to list permissions assigned to that group.
    • Other commands look like they might be useful for this, but some of them are unclear in their meaning and others I haven't tried.


  • If permissions do not seem to be working, try perm reload -- you may receive an enlightening error message.
  • If perm group list throws an exception with a null pointer, this may be an indication that none of your groups are loading successfully.


adapted from default text included in /config.yml (commented out)

A permission node is a string like 'permissions.build', usually starting with the name of the plugin. Refer to a plugin's documentation for what permissions it cares about. Each node should be followed by true to grant that permission or false to revoke it, as in 'permissions.build: true'. Some plugins provide permission nodes that map to a group of permissions - for example, PermissionsBukkit has 'permissions.*', which automatically grants all admin permissions. You can also specify false for permissions of this type.

Users inherit permissions from the groups they are a part of. If a user is not specified here, or does not have a 'groups' node, they will be in the group 'default'. Permissions for individual users may also be specified by using a 'permissions' node with a list of permission nodes, which will override their group permissions. World permissions may be assigned to users with a 'worlds:' entry.

Groups can be assigned to players and all their permissions will also be assigned to those players. Groups can also inherit permissions from other groups. Like user permissions, groups may override the permissions of their parent group(s). Unlike users, groups do NOT automatically inherit from default. World permissions may be assigned to groups with a 'worlds:' entry.

The cannot-build message is configurable. If it is left blank, no message will be displayed to the player if PermissionsBukkit prevents them from building, digging, or interacting with a block. Use '&' characters to signify color codes.