Whitelists, ops and permissions: keeping your Minecraft server in order

Running a Minecraft server is mostly fun until the day someone breaks into a build, hands out diamond blocks to their friends, or flips on creative mode and starts spawning TNT. Most of that comes down to one thing: who can join, and who can do what once they're in. This guide walks through whitelisting, op levels, LuckPerms, anti grief tools, and the basics of banning and kicking, so you can keep control without giving everyone the keys.

Start with a whitelist

The whitelist is the simplest lock on your front door. With it on, only players you've explicitly added can connect. Everyone else gets bounced at the login screen. If your server is for friends, a community, or a small group, turn it on before you do anything else.

You can flip it on from the console or in game:

/whitelist on
/whitelist add Notch
/whitelist add Steve_2009

That's it. Two players added, everyone else locked out. A few more commands worth knowing:

• /whitelist remove Steve_2009 kicks someone off the list (it won't kick them mid session, but they can't rejoin).
• /whitelist list shows everyone currently allowed.
• /whitelist reload re reads the file if you edited it by hand.
• /whitelist off opens the doors again.

Behind the scenes this writes to whitelist.json in your server folder. You can edit that file directly if you prefer, but using the command is safer because it looks up the player's UUID for you. That matters. Minecraft tracks players by UUID, not name, so if you add someone by name before they've ever joined and they later change their username, things can get messy. Adding them while the server is online sorts the UUID out automatically.

One setting people miss: white-list=true in server.properties needs to match. The /whitelist on command sets it for you, but if you're editing files by hand, check both line up. There's also enforce-whitelist=true, which boots anyone already online who isn't on the list the moment you reload. Handy if you just removed a troublemaker and they're still connected.

Op levels: why /op everyone is a bad idea

Op (short for operator) gives a player admin powers. The temptation, especially early on, is to op your co owners and a couple of trusted friends so they can help run things. Resist that. A full op can do basically anything, including stuff you didn't intend to hand over.

Vanilla Minecraft actually has four op levels, set with op-permission-level in server.properties and stored per player in ops.json:

When you run /op SomeName, it grants them whatever op-permission-level is set to, default 4. So by default, every person you op can stop your server, ban your other admins, and spawn unlimited items. That's a lot of trust for someone who just wanted to be able to fly.

Honestly, on a real community server you should op almost nobody. Keep op for yourself and maybe one person you'd trust with your house keys. For everyone else, use a permissions plugin and hand out only the specific abilities they need. Which brings us to the tool most owners end up living in.

LuckPerms: groups and nodes instead of op

LuckPerms is the standard permissions plugin for Paper and Spigot servers, and for good reason. Instead of all or nothing op, you build groups (like default, builder, moderator, admin) and attach exactly the permissions each one should have. Players get added to a group and inherit its powers.

The idea is permission nodes. A node is a string like essentials.fly or worldedit.region.set that maps to one ability. You grant true to allow it, and you can grant false to explicitly deny something even if a parent group allows it.

Here's a basic moderator group built from the console (you can also use the web editor, which is honestly easier for big setups):

/lp creategroup moderator
/lp group moderator permission set essentials.kick true
/lp group moderator permission set essentials.tempban true
/lp group moderator permission set essentials.mute true
/lp group moderator setweight 50
/lp user Steve_2009 parent add moderator

Now Steve can kick, tempban, and mute, and nothing else. He can't change gamemode, can't stop the server, can't op people. If he goes rogue, the worst he can do is the three things you handed him.

Groups inherit from each other too. Set your builder group to inherit default, and your admin group to inherit builder, and you avoid retyping shared permissions. To check what someone actually has, /lp user Steve_2009 info lays it all out.

A few LuckPerms habits worth picking up

• Use the web editor. Run /lp editor, click the link, drag things around, save. It generates a command to apply your changes. Way nicer than typing dozens of node commands.
• Be careful with wildcard nodes like essentials.*. They're convenient but they hand out every permission in that plugin, including ones added in future updates. Grant specific nodes when you can.
• Set a sensible default group. New players land there automatically, so put basic stuff (chat, /spawn, /tpa) on it and nothing dangerous.

Stopping griefers and rolling back the damage

Permissions stop people from running bad commands. They don't stop a player who's allowed to place and break blocks from tearing down your spawn with their bare hands. For that you want protection and a way to undo damage.

CoreProtect is the plugin most owners reach for. It logs every block placed and broken, every chest opened, every door used, with a timestamp and the player's name. When a build gets wrecked, you can see exactly who did it and roll it back.

The main commands you'll use:

/co inspect

That toggles inspector mode. Now left click a broken block to see what was there and who removed it, or right click to see the history of a spot. It's the first thing to do when someone reports griefing.

Once you know who and when, you roll it back:

/co rollback u:Griefer123 t:2h r:30

That reverses everything player Griefer123 did in the last 2 hours within a 30 block radius of where you're standing. If you go too far, /co restore with the same parameters puts it back. The time format takes things like t:1d for a day or t:30m for thirty minutes.

A quick warning: rollbacks are powerful and they don't ask twice. Always run /co inspect and check the logs first so you target the right player and the right time window. Rolling back two hours of legitimate building because you guessed wrong is a bad afternoon.

For prevention rather than cleanup, a land claim plugin like GriefPrevention or a region plugin like WorldGuard lets players protect their own areas so others can't touch them. CoreProtect is your safety net; claims are the fence.

Kicking and banning

Sometimes you just need someone gone. There's a difference between the two main tools here.

A kick disconnects a player right now but lets them rejoin. It's for "stop doing that" moments, or for nudging someone who's stuck or lagging the server.

/kick AnnoyingDave Take a break and read the rules
/kick AnnoyingDave

A ban stops them from coming back at all. You can ban by name or by IP.

/ban Griefer123 Grief and theft, no appeal
/ban-ip 203.0.113.45 Ban evasion
/pardon Griefer123
/banlist

Banning by name is the normal route. IP bans are heavier and worth using when someone keeps making new accounts to dodge a name ban, but be a little cautious: shared connections and CGNAT mean an IP ban can occasionally catch an innocent player on the same network. If you're using EssentialsX or a plugin like LiteBans, you also get /tempban for time limited bans, which is great for "cool off for 24 hours" situations instead of a permanent boot.

All of this is stored in banned-players.json and banned-ips.json, but use the commands rather than editing those by hand.

Console versus in game commands

You can run most admin commands two ways: typed in chat with a leading slash while you're playing, or typed in the server console (or the console tab in your control panel) without the slash.

The console runs as the server itself, which means it always has full permission. No op needed, no permission node, nothing can take it away. That's exactly why the console is the safest place to run sensitive commands, and also why you should guard access to it. Anyone with console access effectively owns the server.

A couple of practical differences:

• The console has no location, so commands that depend on where you're standing (like a CoreProtect rollback using r: radius) work best in game. From console you'd target by coordinates or a specific area instead.
• If you ever lock yourself out of op or break your permissions setup, the console is your way back in. op YourName typed in the console will fix it. So if your Bytte.cloud panel shows the console going quiet or you can't log in, that tab is your recovery hatch.
• The console keeps a full log, so it's the place to check what happened after the fact.

For day to day moderation, in game is faster. For setup, recovery, and anything where you don't want to rely on a plugin loading correctly, the console wins.

Putting it together

You don't need all of this on day one. Start by turning the whitelist on so only people you trust can join. Keep op for yourself. Install LuckPerms and build a couple of groups so your helpers get just the powers they need. Add CoreProtect early, before you actually need it, because logging only counts from the moment it's running. Then keep /kick and /ban in your back pocket for the rare bad actor who slips through.

Do those things and most of the chaos that wrecks small servers just doesn't happen. And on the day something does go wrong, you'll have the logs to see it and the tools to put it right.