Skip to content

[BUG] [Unraid/Docker] Pre-existing worlds missing transport=raknet in server.properties fail to respond to RakNet pings #349

Description

@mmorys

IMPORTANT: Before Submitting

  • Please search existing issues to ensure this bug hasn't already been reported.
    • If a similar bug was already reported, please add your additional information or confirm you're experiencing the same issue in that existing thread.
  • If you are using a version prior to the latest release, please try updating first to see if the issue persists.
  • Read the troubleshooting docs to see if a workaround or fix has been documented.
  • If your issue is related to the CLI (Command Line Interface), please report your issue in the bsm-api-client repository.
  • Do not remove any sections from this template. Incomplete reports may be closed, delayed or may require more information.

(REQUIRED) Describe the Bug:

A clear and concise description of what the bug is.

Several pre-existing Bedrock worlds stopped accepting client connections. The bedrock_server process for each affected world remained running, the correct UDP/TCP ports were bound at the OS level, and the world loaded with no fatal errors in server_output.txt — but the server never responded to RakNet "unconnected ping" packets, including when tested from localhost inside the same container (ruling out Docker networking, port publishing, or firewall causes).

I compared server.properties across all my worlds and noticed that a world freshly created through BSM had a property that none of my older, pre-existing worlds had:

transport=raknet

Manually adding transport=raknet to server.properties for each affected world and restarting immediately resolved the issue.

I believe BSM's world-creation template may have been updated at some point to include transport=raknet in newly generated server.properties files, but this was not backfilled into existing worlds' server.properties (on world load, server start, or BSM upgrade). Without it, bedrock_server appears to start, bind sockets, and load the world normally, but never properly initializes its RakNet session/transport layer, leaving a server that looks healthy (process alive, ports open, no crash, no fatal errors) but is completely unreachable.

I want to flag that I'm not certain of the actual mechanism — I don't know whether this property is read by BSM itself, passed through to the bedrock_server binary, or both. I'm reporting the empirical fix in case it helps others or points toward the actual underlying bug.

This is a screenshot of the property observed in a newly created world (created through BSM). Adding this property manually to my existing worlds using the Add Custom Property feature at the bottom of this page appears to have solved the broken server problem.

Image

(REQUIRED) To Reproduce:

Steps to reproduce the behavior:

1. Have one or more existing Bedrock worlds managed by BSM, created prior to whatever update introduced the `transport` property in server.properties.
2. Update to/use a recent BSM version that writes transport=raknet for newly created worlds.
3. Create a new world through BSM. Confirm its server.properties includes transport=raknet.
4. Compare against an older, pre-existing world's server.properties. Confirm the property is absent there.
5. Start the older world. Observe: process runs, ports bind, no errors logged, but RakNet pings (and real client connections) never get a response.
6. Manually add transport=raknet to the older world's server.properties and restart. Observe the server now responds normally and clients can connect.

(REQUIRED) Expected Behavior:

A clear and concise description of what you expected to happen.

Pre-existing worlds should continue to function normally after a BSM update, either by having any newly-required server.properties keys backfilled automatically, or by the server defaulting to working behavior (e.g. raknet) when the property is missing. At minimum, I'd expect a warning in the logs if a required property is missing from a world's config, rather than the server silently starting in an unreachable state.

(REQUIRED)Actual Behavior:

A clear and concise description of what actually happened.

Worlds missing transport=raknet in server.properties start without any error, bind their ports correctly, and appear "running" in BSM — but never respond to RakNet pings or accept client connections. There is no log message indicating that a property is missing or that this is the cause. The only way I found the cause was by manually diffing server.properties between a newly-created world and my older, broken worlds.

Environment:

(REQUIRED) Operating System & Version:

Unraid (Docker host). BSM running via dmedina559/bedrock-server-manager:latest Docker image, deployed with Docker Compose.

(REQUIRED) Bedrock Server Manager Version:

Frontend: 1.1.5-dirty
Backend: 3.9.1

(OPTIONAL) Minecraft Bedrock Dedicated Server Version (if relevant):

1.26.30.5 (issue persisted after updating to the latest available Bedrock server version)

(OPTIONAL) Python Version (if relevant):

[Not determined — running via the official Docker image, did not check the interpreter version inside the container]

(OPTIONAL) Browser (if web UI related):

Not applicable — issue is not UI-related.


(REQUIRED) Log Files:

  • Provide relevant logs from your Bedrock Server Manager log file.
  • Paste any relevant logs from log files directly to this issue. For more extensive logs or full log files please attach the relevant log file(s) directly to this issue. If you have multiple files or they are large, please compress them into a .zip archive.
  • Important: Review logs for any sensitive information before uploading and redact if necessary.
  • By default, logs are stored in <data_dir>/.logs/

Note

  • Note on Log Level: Initially, warning/error logs are often sufficient. However, you may be asked to provide more detailed logs by setting logging.level in your BSM Settings to DEBUG, reproducing the issue, and then providing the new logs.
2026-06-19 18:22:56,752 - ERROR - bedrock_server_manager.core.bedrock_process_manager - Error pinging server 'PinkAxolotl': unpack requires a buffer of 2 bytes
2026-06-19 18:23:56,756 - ERROR - bedrock_server_manager.core.bedrock_process_manager - Error pinging server 'DisneyWorld': unpack requires a buffer of 2 bytes
2026-06-19 18:23:56,757 - ERROR - bedrock_server_manager.core.bedrock_process_manager - Error pinging server 'Harry_Potter': unpack requires a buffer of 2 bytes
2026-06-19 18:23:56,759 - ERROR - bedrock_server_manager.core.bedrock_process_manager - Error pinging server 'PinkAxolotl': unpack requires a buffer of 2 bytes

[NOTE: I have only app-log-level errors at this point, not DEBUG-level logs. Happy to reproduce with DEBUG logging enabled if needed — I've since fixed all affected worlds by adding transport=raknet to their server.properties, but can revert one for testing if useful.]

(OPTIONAL) Additional Context:

Add any other context about the problem here that may be relevant.

Worlds affected: 3 out of 7 servers running under this BSM instance, all created before whatever update introduced the transport property. Worlds NOT affected included some with the same behavior packs as affected worlds and some with zero addons, so this does not appear to be addon-related — it correlates specifically with the presence/absence of transport=raknet in server.properties, not with pack content, Bedrock server version, or port number (confirmed by moving an affected world to an entirely new port, which did not fix it, while adding the property did).

Diagnostic steps that ruled out other causes:
- Confirmed correct ports were bound at the OS/socket level (checked /proc/net/udp and /proc/net/udp6 directly)
- Confirmed bedrock_server process was alive and not crash-looping (consistent CPU usage over time, stable PID)
- Confirmed UDP packets were reaching the container successfully end-to-end (tested with a separate raw UDP listener)
- Confirmed the bedrock_server process itself does not respond to a RakNet unconnected ping even from localhost inside the same container, ruling out any Docker/network/firewall cause
- Confirmed updating to the latest Bedrock server version did not resolve the issue
- Confirmed moving the affected world to a different port did not resolve the issue
- Confirmed adding transport=raknet to server.properties and restarting did resolve the issue

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinglinuxLinux OS issues

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions