Setting up LuckPerms

Adding Permissions with LuckPerms

LuckPerms is the recommended permissions plugin for SCS2: it exposes a clean command-line interface for granting nodes, supports inheritance and per-world/per-server contexts, and ships a web editor for bulk edits. The recipes below cover the typical SCS2 setup. Replace default, vip, staff with whatever group names you use.

1. Bootstrap: the default rank

This is the most important step on a fresh install: without these two nodes, regular players cannot configure the toggles in their own claims.

# Let everyone toggle every permission/flag in their claim GUI
/lp group default permission set scs.permission.* true
/lp group default permission set scs.flag.* true

# (optional) Common subcommands. Most inherit from scs.claim/scs.unclaim/scs.claims
# which ship with default: true, but you may want to gate higher-tier ones explicitly:
/lp group default permission set scs.claim.list true
/lp group default permission set scs.claim.menu true
/lp group default permission set scs.claim.invite true
/lp group default permission set scs.claim.tp true
/lp group default permission set scs.claim.see true

2. VIP / donor rank: extra perks

/lp group vip parent add default

# Larger limits (pick whichever number fits your economy)
/lp group vip permission set scs.limit.claims.10 true
/lp group vip permission set scs.limit.chunks.500 true
/lp group vip permission set scs.limit.radius.5 true
/lp group vip permission set scs.limit.members.20 true

# Unlimited claim flight (fly TIME itself is a per-player balance, not a node:
# use /scs player <player> set-fly <seconds>)
/lp group vip permission set claim.fly.infinite true

# QoL features locked behind the rank
/lp group vip permission set scs.claim.fly true
/lp group vip permission set scs.claim.auto-fly true
/lp group vip permission set scs.claim.template true
/lp group vip permission set scs.claim.favorite true
/lp group vip permission set scs.claim.respawn true
/lp group vip permission set scs.claim.set-icon true

3. Staff: granular admin access

Three patterns, pick one:

# Pattern A: full admin (single line, easiest)
/lp group staff permission set scs.admin.* true

# Pattern B: bypass-only (no admin commands, but free movement / edits everywhere)
# Useful for backup / build accounts that should ignore claim restrictions
# without seeing the /scs admin menus.
/lp group staff permission set scs.bypass.* true

# Pattern C: granular (only specific tools)
/lp group moderator permission set scs.admin true                       # /scs itself
/lp group moderator permission set scs.admin.player true                # manage other players' claims
/lp group moderator permission set scs.admin.exportauditlogs true       # CSV exports
/lp group moderator permission set scs.admin.metrics:claims true        # read-only metrics
/lp group moderator permission set scs.admin.metrics:players true
/lp group moderator permission set scs.bypass.enter true                # walk into any claim
/lp group moderator permission set scs.bypass.teleport true             # /spawn/tp anywhere
/lp group moderator permission set scs.bypass.ban true                  # ignore per-claim bans

4. Per-player overrides

# Bump one player above their group's default
/lp user Notch permission set scs.limit.chunks.1000 true

# Temporary perk (24h)
/lp user Steve permission settemp scs.claim.fly true 24h

5. Per-world rules

LuckPerms contexts let you scope a node to a single world, useful when claims are only allowed in survival but not in creative or resource:

# Allow claiming only in the survival world
/lp group default permission set scs.claim true world=survival
/lp group default permission set scs.claim false world=resource

6. Verifying the setup

# Inspect what a player effectively has
/lp user Notch permission info

# Check a single node
/lp user Notch permission check scs.permission.place_block

# Web editor for bulk edits
/lp editor

Limit nodes pick the highest match. A player who inherits scs.limit.claims.5 from default and scs.limit.claims.50 from vip ends up with 50. You don't need to remove the lower one when granting a higher one.

Limit nodes (scs.limit.<type>.<amount>) and admin commands (/scs player <name> set-...) cannot be used together: pick one source of truth per server. See the Limits section.

When a permission looks ignored

Four things explain almost every "this permission does nothing" report, in the order worth checking:

1. You are testing as an operator

An OP bypasses every claim permission and flag — the whole scs.bypass.* family defaults to op, and the permission check treats an operator as holding it. The same is true for anyone with scs.admin.*. Test with a normal account, or de-op yourself first: a claim can look completely unprotected while being perfectly configured.

2. The world mode

Claim permissions only apply in a world whose mode is SURVIVAL or SURVIVAL_REQUIRING_CLAIMS. In DISABLED nothing is enforced at all, and in PROTECTED the per-claim roles are ignored in favour of the single protected-mode permission set. See World Modes.

3. The permission belongs to another action than you think

Several actions look alike but answer to different keys: feeding an animal is FEED_ENTITY while breeding two of them is BREED_ENTITY; opening a mount's inventory is INTERACT_MOUNT_INVENTORY, not INTERACT_ENTITY; lighting a portal is IGNITE_PORTAL, not IGNITE_BLOCK; a player's fire answers to a permission while lava and lightning answer to the FIRE_IGNITE flag.

4. The claim predates the permission

New permissions are backfilled into existing claims at startup with the default from config.yml, so a claim created before an update gets the configured value, not the one you may have set on your newer claims. /scs resetPermission <permission> re-applies one permission to every claim, and /scs resetrole <role> re-applies a whole role.

Denials are silent when the matching not-<permission> message is missing from your language file — if an action is blocked with no message at all, check that key first after a custom translation.