On a Java server, the allowlist controls who may join, while operator status controls in-game commands. Console, hosting-panel, SSH, and RCON access belong to separate accounts. Mixing these layers can give a player more control than you intended.
This guide covers Java Edition on vanilla-compatible servers, including Paper. Run management commands in the console for the correct server instance; omit the leading / there. In player chat, include / and use an account with the required permission. Bedrock uses a separate allowlist system and is outside this guide’s scope.
Restrict who can join first#
Before changing access, make sure you can still reach the console or panel. On a remote server, keep your current admin session open until you have checked the new rule.
Add the players who may join, enable the whitelist, and check the list:
whitelist add PlayerOne
whitelist add PlayerTwo
whitelist list
whitelist on
Remove a player with whitelist remove PlayerOne, then inspect the list with whitelist list. In server.properties, the setting is named white-list; whitelist.json stores the permitted players’ names and UUIDs. Paper’s documentation recommends using /whitelist to manage this data instead of editing the JSON file by hand.
When you run a command in the console, do not prefix it with /. In player chat, use the slash and an account with the necessary permission. Admin discussions show this exact point of confusion: for example, a thread about adding a player by editing the file turns to using a console command. That is one example, not a measure of how common the issue is.
Grant OP only when someone needs in-game commands#
Adding someone to the whitelist does not make them an operator. Operator status should not be your way of describing who you trust to join. Do not rely on possible operator exceptions in whitelist checks: define the player list explicitly and verify behavior on your selected server build.
Use the console to grant or remove operator status:
op PlayerOne
deop PlayerOne
ops.json stores operator status and permission levels. Paper documents levels from 0 through 4; op-permission-level sets the default level for newly granted operators. /op can give broad in-game powers, so do not grant OP just for ordinary access or every small admin task. Paper 1.21 and newer already bundle Spark; separate spark permissions can grant specific diagnostic commands without full OP when the server’s permissions are configured accordingly.
If a moderator only needs a few commands, use a compatible permissions system and grant the smallest relevant set. Permission-node names depend on the plugin and command, so check the documentation for the versions you actually installed. Do not copy another server’s permission list blindly.
Keep game access separate from machine access#
The server console can run commands as the server and usually does not require in-game OP. Give console access only to trusted administrators. A hosting-panel account, SSH system user, and RCON password are separate control paths; revoke each one independently when someone stops helping you administer the server. If you manage your own infrastructure through Nexardo, check panel access separately from the Minecraft player list and operators.
RCON is disabled by default in Paper’s documented configuration. If you need it, use a unique strong password and restrict network access with a firewall or private network. Do not expose RCON to the public internet or paste its password into screenshots, shell commands, or public logs. If you do not use RCON, keep enable-rcon=false.
Troubleshoot a denied connection or command#
A player sees a whitelist message. Confirm that you are checking the right server and world; inspect whitelist list, verify the player’s name/profile, and confirm that white-list is enabled. That setting limits new connections. enforce-whitelist concerns kicking players who are already online but no longer pass the allowlist; it is a separate case, not the switch that rejects a new login. Do not add the player to OP “just in case”; that does not replace checking the join list.
A player joined but a command is denied. Check whether they are entering it in chat, which OP level they have, and whether a permissions plugin controls that command. If the installed plugin supports it, grant the narrow permission for that command first; do not raise every operator’s level automatically.
The panel, SSH, or RCON does not work. That is a separate account and network path. Check its role and address/access filter independently of whitelist.json and ops.json. Do not enable RCON to fix a player’s join error.
Do not edit ops.json or whitelist.json while the server is running: Paper describes them as data files and recommends managing them through commands. After changes, recheck the list, permissions, and separate admin accounts. When a player no longer needs access, remove them from the whitelist and separately revoke OP if they had it.
