Anleitungen / Server & Leistung
Whitelist, Bann und Op: Die Server-Befehle, die sich anders verhalten als erwartet
Das Whitelisting wirft bereits online befindliche Spieler nicht hinaus, /ban braucht einen Grund, um nützlich zu sein, und das Op-Level ist wichtiger als die Op-Liste. Die Details, die Serverbesitzer beißen.
Die Admin-Befehle sehen einfach aus und sind es meistens auch. Die Fehler entstehen durch drei Verhaltensweisen, die aus der Syntax nicht ersichtlich sind.
Whitelist entfernt nicht, wer bereits drin ist — es sei denn, du sagst es ihm
/whitelist on beginnt, die Liste für neue Anmeldungen durchzusetzen. Ob bereits verbundene Spieler hinausgeworfen werden, entscheidet eine einzige Zeile in server.properties:
enforce-whitelist=trueStandardmäßig ist sie false, und solange das so ist, bleiben nicht gelistete Spieler sowohl über /whitelist on als auch über /whitelist reload verbunden. Setze sie auf true, und on, reload und remove werfen alle verbundenen Spieler hinaus, die nicht auf der Liste stehen. Die Whitelist einzuschalten, während die Durchsetzung aus ist, und dann wegzugehen, ist der klassische Fehler.
Zwei weitere Details:
/whitelist add <name>löst den Namen auf einem Online-Mode-Server gegen Mojangs API auf. Auf einem Offline-Mode-Server wird stattdessen die Offline-UUID des Namens auf die Whitelist gesetzt, sodass keine manuelle Bearbeitung vonwhitelist.jsonnötig ist.- Operatoren umgehen die Whitelist standardmäßig, weshalb dein eigener Account nie beweist, dass die Whitelist funktioniert. Teste mit einem zweiten Account.
/ban will einen Grund, und /ban-ip ist eine andere Liste
/ban <player> [reason]
/ban-ip <address|player> [reason]Der Grund ist optional, und ihn wegzulassen ist ein Fehler — er ist das, was der gebannte Spieler sieht, und er ist das, was dein zukünftiges Ich in /banlist liest, um sich zu erinnern, warum. Ohne einen steht im Eintrag nur „Banned by an operator".
/ban und /ban-ip schreiben in getrennte Dateien (banned-players.json, banned-ips.json). Das Begnadigen des einen löscht nicht das andere, was der übliche Grund dafür ist, dass ein „begnadigter" Spieler sich immer noch nicht verbinden kann. Verwende /pardon und /pardon-ip beide.
Op-Level, nicht nur die Op-Liste
/op gewährt standardmäßig Level 4, was vollen Zugriff einschließlich /stop bedeutet. Die vier Level sind real und in server.properties über op-permission-level einstellbar:
| Level | Gewährt |
|---|---|
| 1 | Umgehung des Spawn-Schutzes |
| 2 | Die meisten Cheat-Befehle, Command Blocks |
| 3 | Spielerverwaltung — kick, ban, op |
| 4 | Alles, einschließlich /stop |
Moderatoren, die /kick und /ban brauchen, wollen Level 3, nicht 4. Level 4 an jeden auszugeben, der beim Moderieren hilft, ist der Weg, wie Server durch einen kompromittierten Account zerstört werden.
function-permission-level ist separat und steuert, welche Datapack-Funktionen ausgeführt werden dürfen — es bei 2 zu belassen, während das Op-Level 4 ist, ist eine häufige Ursache für „meine Funktion tut nichts".
Die Listen-Befehle
/banlist players, /banlist ips und das einfache /banlist existieren alle und geben in die Konsole statt in den Chat aus, wenn sie vom Server-Terminal aus ausgeführt werden. /whitelist list zeigt nur Namen, keine UUIDs — lies whitelist.json, wenn du die Identität überprüfen musst.
Baue jeden dieser Befehle mit den Argumenten in der richtigen Reihenfolge im Server Admin Command Builder, der ban, ban-ip, pardon, kick, op, deop und whitelist aus einem Formular abdeckt.