Here you will find the messages that show up in the server log around Bedrock players. They come from two directions: On a Java server, the Geyser plugin translates the connection of Bedrock players, and Floodgate lets them join without a Java account. On a native Bedrock server (Bedrock Dedicated Server), the messages usually come from add-ons, meaning behavior and resource packs.

Each section covers exactly one message. You can find the full wording in the Console, and on Java servers also under Files in logs/latest.log. Also read the lines directly below it, because they often name the affected pack or the actual cause.

Before you change configuration files, add-ons or world files, create a backup under Backups. That way you can return to the old state at any time.

Geyser Cannot Load Its Locale Files

What the message looks like:

java.lang.AssertionError: Unable to load Geyser locale map for <Language>
    at Geyser-Spigot.jar//org.geysermc.geyser.text.GeyserLocale.loadGeyserLocale(GeyserLocale.java:141)

What is behind it: For every Bedrock player, Geyser needs the Minecraft language file for their language setting, for example German or British English. Geyser downloads these files at startup and stores them in its own folder. If the download failed at startup or the folder is damaged, Geyser cannot find the file. The Bedrock player's join then fails, while Java players are not affected.

How to fix it:

  1. Restart the server via the Console. Geyser downloads the locale files again in the process.
  2. Watch the startup in the console. If it says "Unable to download and extract … locale", the download itself has already failed. There is a separate section on this further below.
  3. If the message remains, stop the server and, under Files, delete the folder plugins/Geyser-Spigot/locales or Geyser's .cache folder.
  4. Start the server again and let a Bedrock player join.

Good to know: These folders only contain data that Geyser downloads again by itself. Your settings in config.yml are kept.

Geyser Reports an Error in a Bedrock Player's Session

What the message looks like:

[Geyser-Spigot] Exception caught in session of unknown (pre-login)
[Geyser-Spigot] Error thrown in <Player>'s event loop!
[Geyser-Spigot] An exception occurred:

What is behind it: For every Bedrock player, Geyser runs its own session and translates everything that passes back and forth between the Bedrock client and the Java server. If something went wrong during this translation, usually only that one player is disconnected. The server and all other players keep running. "pre-login" means the connection was already dropped before login. A ReadTimeoutException below it points to a broken connection.

How to fix it:

  1. Note the time, the affected player and what they were doing, for example opening a menu or changing worlds.
  2. Update Geyser and Floodgate under Plugins to the latest version. If you uploaded them yourself, replace the old JAR files in plugins/ instead of placing new ones next to them.
  3. Restart the server and have the player repeat the action.
  4. If the error keeps occurring for the same player or action, report it with the error line and the lines below it in the Geyser project's Discord.

Good to know: Bedrock clients receive updates frequently, and an outdated Geyser often cannot cope with new clients. You can ignore a single message with "pre-login" if no player reports a problem.

An Add-on Reports a Script Error

What the message looks like:

[Scripting] [<Add-on>] LocationInUnloadedChunkError: Trying to access location (<x>, <y>, <z>) which is not in a chunk currently loaded and ticking.
[Scripting] [<Add-on>] InvalidEntityError: Failed to get property 'dimension' due to Entity being invalid (has the Entity been removed?).

What is behind it: Many Bedrock add-ons include their own scripts in the behavior pack. These lines are reported by the add-on's script itself, so the error lies in the add-on and not in the server. Typical causes are accesses to an entity that no longer exists or to an area that is not currently loaded. The server keeps running, and usually only one function of the add-on briefly fails. With a very large number of messages, the add-on can hurt performance.

How to fix it:

  1. Read off the name of the add-on. It is in the second square bracket.
  2. Compare your server's Bedrock version under Version with the versions the add-on's author lists.
  3. If there is a newer release of the add-on, create a backup and install it following its instructions.
  4. If the add-on disrupts the game, deactivate it as a test. To do so, under Files, remove its entry from worlds/<World>/world_behavior_packs.json and restart.

Good to know: Content that only the add-on brings along can disappear from the world when you deactivate it. Only the author can fix the error in the script; the lines with "at" help them with that.

Add-on Packs Cannot Be Loaded Cleanly

What the message looks like:

The following issues were found when loading packs:
    behavior_packs/<Package>
        The property '/header/min_engine_version' has a version of '<Version>' which is too high. The highest value we accept is '<Version>'.

What is behind it: Every add-on pack has a description file called manifest.json. It contains, among other things, the name, identifier, version and the minimum Bedrock version the pack needs. If the server finds errors there at startup, it lists them indented below this line: first the pack, below it the cause. Depending on the error, it does not load the pack at all or loads it differently than intended, for example as a resource pack instead of a behavior pack ("Defaulting to resource pack").

How to fix it:

  1. Read the indented lines below the message. They name the pack and the cause.
  2. If it says "too high", the add-on needs a newer Bedrock version than your server has. Use an older release of the add-on or wait until the matching version is available under Version or Updates.
  3. For other causes, the author's current release of the add-on usually helps.
  4. If you edited manifest.json yourself, check it under Files. It must be valid JSON (brackets, commas, quotation marks) and contain all required fields, for example format_version, header with name, uuid and version, as well as modules.
  5. Restart and check whether the list has disappeared.

The Geyser Configuration Cannot Be Read

What the message looks like:

[Geyser-Spigot] Failed to read/create config.yml! Make sure it's up to date and/or readable+writable!
org.geysermc.geyser.platform.spigot.shaded.org.spongepowered.configurate.loader.ParsingException: …

What is behind it: Geyser reads its settings from plugins/Geyser-Spigot/config.yml. The file is written in YAML, a text format in which indentation with spaces and colons determine the structure. A ParsingException below it means the file is damaged at one spot, often after editing by hand. Less commonly, it is outdated or not readable or writable. Without a valid configuration, Geyser usually does not start, and Bedrock players cannot join the server. Java players notice nothing.

How to fix it:

  1. Stop the server and, under Files, open the file plugins/Geyser-Spigot/config.yml.
  2. Check the lines named in the error message: tabs instead of spaces, shifted indentation, a missing colon or an unclosed quotation mark.
  3. If you cannot find the error, rename the file, for example to config.yml.alt. Geyser creates a new default file at the next start.
  4. Afterwards, transfer only the necessary values from the old file. The Bedrock port must match the UDP port that the panel assigns to your server.
  5. Start the server and check in the Console whether Geyser starts without errors.

Good to know: If even a freshly generated file reports the error, it is more likely due to file permissions. If you get stuck, open a ticket and include the time of the message.

Floodgate Is Loaded Twice

What the message looks like:

java.lang.IllegalArgumentException: Duplicate handler name: floodgate-init

What is behind it: At startup, Floodgate hooks into the server's network connection so that it can recognize Bedrock players. This hook may exist only once. The message shows that Floodgate was loaded a second time. Usually there are two Floodgate files in the plugins/ folder, for example an old and a new version. Sometimes another plugin also bundles Floodgate itself. Bedrock players may then fail when joining.

How to fix it:

  1. Under Files, open the plugins/ folder and look for all files that have "floodgate" in the name and end in .jar.
  2. Keep only one of them, ideally the newest, and delete the rest.
  3. For recently installed plugins, check whether their description says they include Floodgate. In that case you only need one of the two sources.
  4. Restart the server and let a Bedrock player join.

Good to know: The folder plugins/floodgate is not a second plugin. It contains Floodgate's settings and key and stays in place.

An Add-on Contains Entries the Server Does Not Understand

What the message looks like:

[FeatureRegistry] Feature rule <add-on>:<name> can't place internal feature type.
[Animation] Error: can't find animation <name>

What is behind it: Add-ons describe entities, items, blocks, animations and parts of world generation in their own files. If the Bedrock server does not understand one of these entries in its version, it writes such a line to the log. "Feature rule" concerns, for example, rules that distribute plants or structures in the world. That part of the add-on then does not work or only partly works, while the rest and the server keep running. Usually the add-on was built for a different Bedrock version.

How to fix it:

  1. Find the affected pack. The part before the colon is usually the add-on's abbreviation, and other lines name the path behavior_packs/….
  2. Check under Version which Bedrock version your server has.
  3. Create a backup, download from the author the release of the add-on that matches this version, and replace the old pack.
  4. Restart and check whether the lines disappear.

Good to know: After a Bedrock server update, such lines often appear in large numbers until the authors have adapted their add-ons.

Geyser Expects Floodgate, but Floodgate Is Missing

What the message looks like:

Auth-type set to Floodgate but Floodgate is not installed

What is behind it: In the Geyser configuration, the login type is set to floodgate. This is meant to let Bedrock players join without an additional Java account. For that, however, the Floodgate plugin must be installed and active. If it is missing, Geyser shuts itself down, and Bedrock players cannot join the server. Java players are not affected.

How to fix it:

  1. Check under Plugins or in the plugins/ folder whether Floodgate is present and whether it reports an error of its own at startup.
  2. If it is missing, install Floodgate from the same source as Geyser and matching your server software into the plugins/ folder.
  3. If you do not want to use Floodgate, instead set the value auth-type to online in plugins/Geyser-Spigot/config.yml. Bedrock players then additionally need a Java account.
  4. Restart the server and test joining with Bedrock.

In detail: Set Up Bedrock Crossplay with Geyser and Floodgate

Geyser Cannot Download the Locale Files

What the message looks like:

[Geyser-Spigot] Unable to download and extract <Language> locale!

What is behind it: At startup, Geyser downloads the Minecraft language files from Mojang. Here this connection was interrupted, and below it you will usually see "Connection reset". Until the next successful start, Bedrock players see untranslated texts or cannot join at all. The server itself and Java players are not affected.

How to fix it:

  1. Restart the server. Often the download works on the next attempt.
  2. During startup in the Console, watch whether the message appears again.
  3. If it remains, stop the server and, under Files, delete the folder plugins/Geyser-Spigot/locales or Geyser's .cache folder.
  4. Start again and test joining with Bedrock.

Good to know: If the message "Unable to load Geyser locale map" follows when joining, it is usually a consequence of this failed download. If it fails over several starts, open a ticket and include the time of the message.

Geyser Cannot Reach a Required Network Service

What the message looks like:

[Geyser-Spigot] Got an error
java.net.ConnectException: Connection refused

What is behind it: For its work, Geyser establishes connections to other endpoints, for example to a configured remote host or to external services. Here one of these connections could not be established. The line directly below names the cause: ConnectException means the remote host refused, often because nothing is running there. NoRouteToHostException means the address is not reachable at all. What fails depends on the remote host.

How to fix it:

  1. Read the lines below "Got an error" in full. Often the address Geyser wanted to reach is listed there.
  2. If you changed a target address or port in plugins/Geyser-Spigot/config.yml, compare it with the details in the panel and correct it.
  3. If the target is on another server, check whether it is running and reachable.
  4. Update Geyser under Plugins and restart the server.

Good to know: If the message appears only once and Bedrock players can still join the server, you can observe it for now instead of intervening immediately.

Geyser Cannot Open Its Bedrock Port

What the message looks like:

[Geyser-Spigot] Failed to start Geyser on <IP>:<Port>

What is behind it: Geyser accepts Bedrock connections via its own UDP port. UDP is the network protocol that Bedrock uses for the connection. Geyser could not open this port: Either another service already occupies it, or it is not assigned to your server and therefore cannot be used. Bedrock connections then do not work, while Java players can still join the server.

How to fix it:

  1. Check in the panel which Bedrock port (UDP) is assigned to your server.
  2. Under Files, open the file plugins/Geyser-Spigot/config.yml and compare the value port in the bedrock section. It must exactly match the assigned port.
  3. Check whether another UDP service uses the same port, for example the query (query.port in server.properties) or a voice chat plugin. Each of these services needs its own port.
  4. Save, restart the server and test joining with Bedrock.

In detail: Bedrock Crossplay: Geyser, Floodgate and UDP Port

An Add-on's Script Hung and Was Terminated

What the message looks like:

[Watchdog] Unhandled critical exception of type '<Type>' in behavior pack '<Add-on>'

What is behind it: The Bedrock server monitors the add-ons' scripts with a guard, the watchdog. If a script takes too long, the server terminates it so that the whole world does not freeze. The message shows the add-on's name after "behavior pack". At that moment the server may stutter briefly, and functions of the add-on fail. The server itself keeps running.

How to fix it:

  1. Read the add-on's name from the message.
  2. Check with the author whether there is a newer release for your server's Bedrock version (see Version), and install it after creating a backup.
  3. Watch whether the message appears during a specific action, for example when entering an area or when many entities are in one place.
  4. If it occurs often, deactivate the add-on as a test and observe whether the stuttering disappears.

Good to know: A single message is no cause for concern. What matters is whether it repeats.

A Permission Entry Without XUID or Level

What the message looks like:

xuid or permission missing from permissions file

What is behind it: On a Bedrock server, the file permissions.json defines who has which permission level, for example operator. Each entry needs two details: the XUID, meaning the permanent identifier of the Xbox or Microsoft account, and the level. If one of them is missing, the server cannot assign the entry to a player and does not apply it. The server runs normally, only this permission does not take effect.

How to fix it:

  1. Open your server's server configuration and there the section "Permissions (Ops)".
  2. Delete the line without an XUID or add the player's XUID.
  3. Restart the server afterwards.
  4. It is easier with the command op <Player> in the Console while the player is online. The server then enters the XUID itself.

Good to know: On Bedrock, the XUID counts, not the player name. An entry without an XUID therefore remains ineffective, even if the name is correct.

Your message isn't listed?

Read the whole message in the Console or in logs/latest.log, including the lines directly before it. If a stack trace follows, meaning a list of lines beginning with "at", it shows where the error originated. Names such as Geyser-Spigot.jar or floodgate in it reveal the affected plugin. On Bedrock servers, square brackets or paths under behavior_packs/ name the add-on. Create a backup before you change anything. If you get stuck, open a ticket and include the time of the message.