I’ve been getting asked to put this together for years including in official GitHub issues. I always knew it would be a great idea but it turned out even better than I expected. This image works great on all platforms including Raspberry Pi!
Sets up the official Minecraft Bedrock Server (currently in alpha testing)
Fully operational Minecraft Bedrock edition server in a couple of minutes
Adds logging with timestamps to “logs” directory
Multiarch Support – all Docker platforms supported including Raspberry Pi
Automatic backups when container/server restarts
Supports multiple instances — you can run multiple Bedrock servers on the same system
Updates automatically to the latest or user-defined version when server is started
Files stored in named Docker volume allowing for extremely easy access/editing and leveraging more advanced Docker features such as automatic volume backups
*NEW* – Box64 support added for improved speeds on aarch64 (ARM 64 bit)
Usage
First you must create a named Docker volume. This can be done with:
docker volume create yourvolumename
Now you may launch the server and open the ports necessary with one of the following Docker launch commands.
The server data is stored where Docker stores your volumes. This is typically a folder on the host OS that is shared and mounted with the container. I’ll give the usual locations here but if you’re having trouble just do some Googling for your exact platform and you should find where Docker is storing the volume files.
You can find your exact path by typing:
docker volume inspect yourvolumename
This will give you the fully qualified path to your volume like this:
This is useful if Microsoft hasn’t released versions of the client and dedicated server at the same time so you can match whichever version your players can connect with.
Clean Environment Variable
If the server is having trouble starting you can clean the downloads folder and force reinstallation of the latest version like this:
This is useful if a download corrupted or something modified your container contents as it will clear everything out and reinstall the latest Bedrock server fresh.
Disable Box64 (aarch64 only):
If you are having trouble running the dedicated server with Box64 support you can tell it to use QEMU instead with:
A very common problem people have with the Oracle Virtual Machine tutorials out there that typically show you how to use a free VM is that the VM is much more difficult to configure than just about any other product / offering out there.
It is because there are several steps you need to take to open the ports on the Oracle VM. You need to both:
Set the ingress ports (TCP/UDP) in the Virtual Cloud Network (VCN) security list
*and* set the ingress ports in a Network Security Group assigned to your instance
Both of these settings are typically required before you will be able to connect to your VM instance. This is purely configuration related and has nothing to do with the script or the Minecraft server itself.
I do not recommend this platform due to the configuration difficulty but the people who have gone through the pain of configuring an Oracle VM have had good experiences with it after that point. Just keep in mind it’s going to be a rough ride through the configuration for most people.
Troubleshooting Note – Hyper-V
There is a weird bug in Hyper-V that breaks UDP connections on the Minecraft server. The fix for this is that you have to use a Generation 1 VM with the Legacy LAN network driver.
There is a second fix that was shared by bpsimons here. For that fix you need to install ethtool first with sudo apt install ethtool. Next in your /etc/network/interfaces file add “offload-tx off” to the bottom as the issue appears to be with TX offloading.
Here’s an example:
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.5
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
offload-tx off
This can also be done non-persistently with the following ethtool command:
ethtool -K eth0 tx off
Additional Support
The comments section right here is the best place for support. The second best place is the GitHub issues section.
I will add additional documentation based on what problems people are running into / questions people are asking because right now I’m not really sure what those will be yet. Definitely let me know if you need any of these things!
158 thoughts on “Legendary Minecraft Bedrock Container”
bpsimons
I got the ethtool Hyper-V fix to persist across reboots on Ubuntu 20.04.
Assuming you have ethtool installed (apt install ethtool) you can add “offload-tx off” to your /etc/network/interfaces, and Ubuntu will automatically run the ethtool command when it ups the interface. For example, my /etc/network/interfaces section for eth0 now looks like this:
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.5
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
offload-tx off
Perfect! That makes sense that it wouldn’t have persisted otherwise. That’s a neat /etc/network/interfaces trick. I’ve literally never seen anyone specify those parameters in that file for this. Very cool!
I will definitely add this into the documentation for sure!
Something to add to the “Troubleshooting Note – Hyper-V”
I was experiencing the Hyper-V issue where Minecraft could ping my Bedrock Server but couldn’t join it. I’m running your Bedrock scripts on an Ubuntu Gen 2 Hyper-V VM on Windows 10.
This command immediately fixed the issue for me:
ethtool -K eth0 tx off
It seems like TX Checksum Offloading might be where the bug in Hyper-V exists, so disabling it with the above command gets around the bug. Not sure whether this command will persist across a reboot, but it’s a super easy solution. Hopefully it helps others.
Excellent, thanks for leaving this! Previously we had no idea how to fix them. I just told people to turn it back to Gen1 and that got them working (but is technically more of a workaround, yours is an actual fix).
I’ll add this to the documentation as a (almost certainly better) solution as well!
Great question! The easiest way is to use the instructions to get to your server files. In there there is a “backups” folder. This will do a backup each time your server starts.
To restore these backups you would basically just uncompress them into your Docker volume’s folder. Hopefully that helps!
All glory to James
My build:
Dell Wyse 5070 Thin Client Install (Pentium)
Install Ubuntu Server 22.04 LTS on device including SSH (Named:wyseserver)
1. Use Putty from windows machine to connect to wyseserver
2. Install updates: sudo apt update && sudo apt upgrade -y && sudo apt autoremove -y
3. Reboot: reboot
4. Fix any issues with updates: sudo apt --fix-broken install
5. Install docker: sudo curl -fsSL get.docker.com | sh
6. Create volume for portainer (portainer pretty kewl but not required) : docker volume create portainer_data
7. Install portainer: docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest
8. Install NFS so I can access the data from my Windows computer (PS install the Service for NFS features on Windows machine and don’t forget to start the service when done): sudo apt install nfs-kernel-server
9. Enable the NFS Service to start when server starts: sudo systemctl enable nfs-kernel-server.service
10. Start the NFS Service: sudo systemctl start nfs-kernel-server.service
11. Make some directories for a few persisten volumes for the data for the docker containers (make as many as you need servers): sudo mkdir -p /mnt/dvols/mcsvol01
sudo mkdir -p /mnt/dvols/mcsvol02
sudo mkdir -p /mnt/dvols/mcsvol03
12. Give nobody and nogroup permissions to these folders: sudo chown -R nobody:nogroup /mnt/dvols/mcsvol01
sudo chown -R nobody:nogroup /mnt/dvols/mcsvol02
sudo chown -R nobody:nogroup /mnt/dvols/mcsvol03
13. Give read write permissions to these folders: sudo chmod 777 /mnt/dvols/mcsvol01
sudo chmod 777 /mnt/dvols/mcsvol02
sudo chmod 777 /mnt/dvols/mcsvol03
14. Now give access to a specific ip or range to these NFSs: sudo nano /etc/exports
Enter the IP or Range or subnet of the machine that you use to access the NFS /mnt/dvols/mcsvol01 192.168.0.0/24(rw,sync,no_subtree_check)
/mnt/dvols/mcsvol02 192.168.0.0/24(rw,sync,no_subtree_check)
/mnt/dvols/mcsvol03 192.168.0.0/24(rw,sync,no_subtree_check)
15. Save the File: Ctrl+X,Y,Enter
16. Update the NFS Table: sudo exportfs -a
17. Restart the NFS SerVice: sudo systemctl restart nfs-kernel-server
18. Check the status of the service if you are so inclined (absolutely optional): sudo -i
systemctl status nfs-kernel-server
exit
19. Allow NFS through firewall from specific IP: sudo ufw allow from 192.168.0.0/24 to any port nfs
20. Create some persistent docker volumes and bind them to the folders we created earlier (make as many as you need servers): docker volume create --driver local --opt type=none --opt o=bind --opt device=/mnt/dvols/mcsvol01 mcserver01vol
docker volume create --driver local --opt type=none --opt o=bind --opt device=/mnt/dvols/mcsvol02 mcserver02vol
docker volume create --driver local --opt type=none --opt o=bind --opt device=/mnt/dvols/mcsvol03 mcserver03vol
21. Create the servers (again as many as you need) (my ports follow sequence 19 server# 2/3): docker run -it -v mcserver01vol:/minecraft --name mcserver01 --restart=always -e NoScreen=Y -e TZ="Australia/Sydney" -p 19012:19012/udp -p 19012:19012 -p 19013:19013/udp -p 19013:19013 -e PortIPV4=19012 -e PortIPV6=19013 05jchambers/legendary-bedrock-container:latest
docker run -it -v mcserver02vol:/minecraft --name mcserver02 --restart=always -e NoScreen=Y -e TZ="Australia/Sydney" -p 19022:19022/udp -p 19022:19022 -p 19023:19023/udp -p 19023:19023 -e PortIPV4=19022 -e PortIPV6=19023 05jchambers/legendary-bedrock-container:latest
docker run -it -v mcserver03vol:/minecraft --name mcserver03 --restart=always -e NoScreen=Y -e TZ="Australia/Sydney" -p 19032:19032/udp -p 19032:19032 -p 19033:19033/udp -p 19033:19033 -e PortIPV4=19032 -e PortIPV6=19033 05jchambers/legendary-bedrock-container:latest
22. Going to stop the first server so I can copy in my worlds, edit properties, textures so on…: docker stop mcserver01
23. Make permissions nobody and nogroup so I can edit the contents: sudo chown -R nobody:nogroup /mnt/dvols/mcsvol01
24. Navigate to folder from my windows PC and do all changes I require. \\wyseserver\mnt\dvols\mcsvol01
25. Start Docker contrainer up again as complete with my changes (I’m assuming the fixpermissions.sh is run on startup James?): docker start mcserver01
26. Access the terminal of the docker container: docker exec -it mcserver01 bash
28. Run the fix permissions script if required (Again not sure if required James?) cd scripts
./fixpermissions.sh
29. Exit the docker container terminal safely: Ctrl+P+Q
Wow, that is a great and fully complete build, great work! Thanks for such a detailed writeup as well as you’ve really covered a lot of things here that are not in the documentation yet but that I’m sure many others will want to do. This is fantastic!
I can answer about the fixpermissions.sh script. It should run this itself every time the server starts but yes in this situation I would run it manually to be sure. Essentially any time you are moving files, creating new folders, or editing the server files the ownership of the files tends to get messed up. In other words if you edit and save the file as root or another user that user will own the files which will start to cause crashes in the Minecraft server. The fixpermissions.sh script prevents this by taking ownership by the user that is running the server basically so everything matches up how it should.
Thank you for writing this! It’s like a “big picture” guide that shows a lot of cool Docker features / options to manage the feature that are not in the main documentation. Enjoy and take care!
This Docker version worked really good! Thank you for this! 😀
However i noticed something that i couldn’t manage to figure out.
How do we access the terminal of the server itself?
I wanted to give character admin role by writing “/OP [name]”
But i can’t seem to figure out how and where to even start the server again after we reboot our Raspberry pi 🙁
Thanks for the kind words! That is an understandable question! So to start the container again you just run the same command again to start it. It should take you straight into the console when you start it and then you can type “op yourplayer” (leave the forward slash off) and that should take care of it for you!
If the Docker container is in the background you can use:
sudo docker container ls
to see all the running containers and their IDs. We can then attach to them with:
sudo docker container attach yourcontainerid
That will take care of it even if it’s running in the background!
I’m glad you got it working! So for the updates basically it will update every time you restart the server. If it’s still saying outdated version that means that Microsoft hasn’t put the updated version on their web site yet (that’s where the script downloads the latest available version from).
If you think things might be stuck you can launch the container with the Clean=Y flag to make it redownload it but it won’t help if Microsoft hasn’t uploaded a new version. My guess is this is likely resolved by now or others would be here so I think a restart should take care of it!
Hello, I think what you’re doing is really cool and the fact that you somehow managed to make this work on ARM even though Microsoft didn’t make an Arm build of their own server software (kinda dumb considering you can host a world on an ARM device so it’s obviously possible, I’ve even installed lineage OS and tested Bedrock on this Pi, though the gpu didn’t like that very much). Unfortunately I’ve been having trouble whenever I try to run the server it comes up with some errors and then it says:
Unable to connect to update website (internet connection may be down). Skipping update ...
Even though I can pull the latest version without issue. It then says “Starting Minecraft server…” and terminates instantly with no explanation. I noticed another commentor had this issue as well but you made an updated version to fix that issue and it worked for them, so I have no idea why it’s happening, unless it’s possibly a different problem causing the same outcome. I haven’t actually been able to start the server once, it’s done the same thing since I started following your tutorial. I tried apt update and apt upgrade to make sure everything was up to date as well, nothing changed.
On top of that, I am unable to access the docker volume as it supposedly doesn’t exist (sudo docker volume inspect minecraftbedrockserver returns /var/lib/docker/volumes/minecraftbedrockserver/_data as the Mount point) and the /var/lib/docker folder is empty and is 0 bytes in size so there doesn’t seem to be anything in it.
Using a Raspberry Pi 4, 4gb with 32-bit version of Raspberry Pi OS
pi@raspberrypi:~ $ sudo docker run -it -v minecraftbedrockserver:/minecraft -p 19132:19132/udp -p 19132:19132 05jchambers/legendary-bedrock-container:latest
Minecraft Bedrock Server Docker script by James A. Chambers
Latest version always at https://github.com/TheRemote/Legendary-Bedrock-Container
Don't forget to set up port forwarding on your router! The default port is 19132
Ports used - IPV4: 19132 - IPV6: 19133
sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit
Checking for the latest version of Minecraft Bedrock server ...
Unable to connect to update website (internet connection may be down). Skipping update ...
Starting Minecraft server...
[screen is terminating]
pi@raspberrypi:~ $ sudo docker pull 05jchambers/legendary-bedrock-container:latest
latest: Pulling from 05jchambers/legendary-bedrock-container
Status: Image is up to date for 05jchambers/legendary-bedrock-container:latest
docker.io/05jchambers/legendary-bedrock-container:latest
pi@raspberrypi:~ $ sudo docker run -it -v minecraftbedrockserver:/minecraft -p 19132:19132/udp -p 19132:19132 05jchambers/legendary-bedrock-container:latest
Minecraft Bedrock Server Docker script by James A. Chambers
Latest version always at https://github.com/TheRemote/Legendary-Bedrock-Container
Don't forget to set up port forwarding on your router! The default port is 19132
Ports used - IPV4: 19132 - IPV6: 19133
sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit
Checking for the latest version of Minecraft Bedrock server ...
Unable to connect to update website (internet connection may be down). Skipping update ...
Starting Minecraft server...
sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit
It looks like this is a problem with DNS resolution in your Docker environment. I found something here.
I noticed several people in there said that the person had an older Debian Buster install installed. This is extremely common since if you didn’t image your Pi after April 2022 you also have Buster instead of Bullseye which is the latest one. Unfortunately not even a sudo apt-get dist-upgrade will upgrade you to a new release (more on this in a moment).
The reason the volume is empty is because it actually can’t download the bedrock_server. There’s nothing to unzip basically. That is from this message you mentioned:
Unable to connect to update website (internet connection may be down). Skipping update ...
Basically because it can’t resolve the DNS name of the web site it actually can’t download the server from Microsoft if that makes sense.
I think updating the Pi to Bullseye should do it. The fastest way to do it is to just reimage it with the latest Bullseye OS (available in the Pi Imager and from the Downloads section) but it’s possible to upgrade it.
It takes about 5 times longer to upgrade it than to reimage it and there’s a lot of steps and issues to watch out for so I highly recommend doing a fresh install of Bullseye. If there’s a lot of other stuff or configuration done on the Pi though an upgrade is possible (do backups first). I highly, highly recommend the 64 bit version of Bullseye. It will be much, much slower in 32 bit because it can’t use Box64. It’s honestly a perfect chance to reimage it with a 64 bit OS. It’s nearly unplayable in 32 bit (although some people still run it on there and it’s fast enough for them but I would say it’s too slow).
There’s another option as well. You can actually run a Java server that Bedrock and Java players can both connect to using this version of the container: Minecraft Java + Bedrock Together: Geyser + Floodgate. This will be fast on 32 bit although the Docker will probably still have that same DNS issue without an upgrade to Bullseye.
Bullseye should for sure take care of the Docker issues for you!
Wow that was fast! Thank you, that makes sense because this pi had been unused for about a year. Will reimage it with the 64-bit version of Bullseye and get back to you in case it might help someone else with the same issue.
No problem at all, thank you for asking this as I don’t think it has come up in this article at all (the container is still relatively new) and I’m certain it will help others as well.
I’m not sure I’ve seen that specific error message ever before either as I had to do some research on that one. The Bullseye vs Buster fix has come up before on the standalone container but with totally different errors/symptoms. Your post is the first documentation of this issue on Docker that I have and I appreciate you giving such thorough logs (that definitely helped me diagnose it as far as I was able to for sure).
Definitely feel free to stop stop by if you run into any issues and enjoy!
So I reimaged the Pi with Bullseye 64-bit and re-did everything from scratch including a mumble server and smb server, as well as installing box64, and then set up your docker container. I got no errors and was able to join without issue. The first join took about a minute or two (pi was generating the nearby chunks) everything seemed normal, there were animals as well. After the initial generation it took about 30-45 seconds to join.
I didn’t notice much lag though the first command entered on either the server CLI or on an operator client seems to always produce a giant lag spike and everything in the game freezes for about 30-60 seconds and then it’s suddenly fine. Teleporting to unloaded chunks seems to do the same thing as well, though I didn’t do a lot of testing. I do believe most of the problems can be a attributed to lack of an SSD or other decent storage options, current storage is a 200gb micro SD card. I imported a creative world to the docker volume and used that for the server and noticed some lag with pressure plates connected to iron doors and would end up walking into the door before it opened.
Planning on using a faster storage option in the future, though I’m not sure how I would move a docker volume to a different drive it’s probably pretty easy. This seems like a viable solution and would work fine for a dedicated Bedrock server when using a faster storage device. Amazing work!
Congratulations and excellent work! You’re 100% right about all of your observations here. The delays you are observing from joining and teleporting/going to unloaded chunks are storage bottlenecking. The SSD does an amazing job dramatically reducing those times.
For moving the Docker contents to a different volume if you use sudo you can navigate to the Docker volume contents as just a hard drive folder (see the accessing files section for more on this, there’s a command you can use to get the exact folder on the drive listed there). Essentially you can copy them and create a new Docker volume on the host with docker volume create yourvolume. That would give you an empty folder to copy the files into from the old server/system.
Thanks for sharing a detailed account of your experience, I’d love to hear how it goes if you are able to test it with a SSD as well in the future. Take care!
at first I’d like to thank you to make it so easy to set up a minecraft server on a raspberry for us! Great work. But I still run into a bit of trouble. I am using a Raspberry Pi 4 with 4 GB of ram and a Raspberry Pi OS (64 bit). The Server starts perfectly fine and delivers the following output:
[2022-07-21 14:49:31] NO LOG FILE! - setting up server logging...
[2022-07-21 14:49:31] [2022-07-21 14:49:31:612 INFO] Starting Server
[2022-07-21 14:49:31] [2022-07-21 14:49:31:616 INFO] Version 1.19.10.03
[2022-07-21 14:49:31] [2022-07-21 14:49:31:616 INFO] Session ID 779e793e-60db-408f-a088-9e9bf9d4c61e
[2022-07-21 14:49:31] [2022-07-21 14:49:31:655 INFO] Level Name: Bedrock level
[2022-07-21 14:49:32] [2022-07-21 14:49:32:710 INFO] Game mode: 0 Survival
[2022-07-21 14:49:32] [2022-07-21 14:49:32:711 INFO] Difficulty: 1 EASY
[2022-07-21 14:49:33] [2022-07-21 14:49:33:119 INFO] opening worlds/Bedrock level/db
[2022-07-21 14:50:05] [2022-07-21 14:50:05:540 INFO] IPv4 supported, port: 19132
[2022-07-21 14:50:05] [2022-07-21 14:50:05:550 INFO] IPv6 not supported
[2022-07-21 14:50:15] [2022-07-21 14:50:15:798 INFO] Server started.
[2022-07-21 14:50:15] [2022-07-21 14:50:15:858 INFO] ================ TELEMETRY MESSAGE ===================
[2022-07-21 14:50:15] [2022-07-21 14:50:15:858 INFO] Server Telemetry is currently not enabled.
[2022-07-21 14:50:15] [2022-07-21 14:50:15:859 INFO] Enabling this telemetry helps us improve the game.
[2022-07-21 14:50:15] [2022-07-21 14:50:15:860 INFO]
[2022-07-21 14:50:15] [2022-07-21 14:50:15:863 INFO] To enable this feature, add the line 'emit-server-telemetry=true'
[2022-07-21 14:50:15] [2022-07-21 14:50:15:864 INFO] to the server.properties file in the handheld/src-server directory
[2022-07-21 14:50:15] [2022-07-21 14:50:15:866 INFO] ======================================================
[2022-07-21 14:50:15] [2022-07-21 14:50:15:013 INFO] IPv4 supported, port: 46660
[2022-07-21 14:50:15] [2022-07-21 14:50:15:013 INFO] IPv6 not supported
[2022-07-21 14:50:31] [2022-07-21 14:50:31:429 INFO] Player connected: XXXXX, xuid: 2535450906092014
I am using a Huwai MediaPad M5 lite 10 with Android 8 and Minecraft 1.19.10 to connect to the server. When connecting it gets stuck at “searching for server” for 2 minutes and 50 seconds until I join the game. The game than starts in an ice biome and works fine at the spawning point. But when I walk away a few chunks the next chunks just won’t load. I am trapped in quite a tiny world. Is there any known reason why it takes so long to join the world or why it is not loading within an acceptable amount of time?
Any hint is appreciated. My boys would love to play on this server 😉
Welcome! I definitely think I can help explain some of what is going on. There are basically two bottlenecks to worry about with the Minecraft server on the Pi. That is basically CPU and your storage device.
It’s pretty common on a Pi to be using a micro SD card as that is the standard. The problem with Minecraft is when you are moving throughout chunks if you’ve never been to those chunks before such as on a new server they have to be completely generated from scratch and then written to storage. The SD card definitely struggles to keep up and that is most of what you are waiting for.
The other bottleneck is the CPU. This is because the Bedrock server isn’t actually available in ARM so I’m “cheating” to run it by using QEMU which is a layer of emulation. I have plans to integrate Box64 into the container sometime this summer which will improve this. Mild overclocks on the Pi can actually help as well with the CPU part of this. Note that the CPU doesn’t explain the level of bottlenecking you are experiencing unless you are running other services on the Pi at the same time. The CPU is the same in the 1GB/2GB/4GB/8GB models and it will *not* bottleneck it to this extent unless it’s competing with something else (at least on the Pi 4).
With all that said from what you’re saying yours sounds a little bit on the slower side to me and I would bet that it’s not using a SSD. It’s definitely not perfect even on a SSD and you’ll experience effects like sometimes you’ll break a block and there will be a slight delay before picking it up. It’s actually playable though and yours sounds like it’s unplayable at the moment. There may be some chunk lag but nothing that would ever trap you in an area like this. It’s actually playable and yours sounds like it’s pretty much unplayable at the moment. High quality SD cards would typically also not bottleneck to this extent and a lot of my testing is done on SD cards (that’s what my Pi 400 is using right now, SanDisk Ultra A1 SD card).
I’ve covered how to upgrade to an SSD for (relatively) cheap (something like a $15 USB to SATA adapter and a Kingston A400 can be had for ~$20 as well) in this guide here.
I would strongly recommend running my storage benchmark from pibenchmarks.com. This will give us an idea of how your disk is performing. This can be done with:
The average score for a SD card is probably something like around 1000 and for a SSD anywhere from 5000-8000. There are definitely SD cards out there such as cards without application class (A1 or A2) that may perform substantially worse and get something like 600-700 points and I wonder if yours will be like that with the intensity of the bottlenecking your are experiencing.
Unfortunately the cost of the SD card doesn’t necessarily always reflect the performance. It may have not been a cheap SD card but if it’s missing a few key things like being application class the performance might literally be 50% of what something like a cheap SanDisk Ultra that does have the A1 classification can perform (and the bottlenecking would roughly be 50% improved in this theoretical scenario because the Pi is just waiting on the disk due to the bottlenecking so you would feel every % point of a 50% improvement in disk performance). I made the storage benchmark at pibenchmarks.com years ago to solve this very question (and it was actually Minecraft that drove me making it in the first place as it makes such a huge difference which SD card you have).
You can actually do some tests on your Pi to confirm the bottlenecks. Running “top” will let you see the CPU usage and “iotop” for disk usage. These are the two factors somewhat in your control via overclocking for the CPU and using something like a SSD (or application class A1/A2 SD cards) for the disk. Hopefully that helps!
I benchmarked my Sandisk Ultra with a score of 1352. I will certainly follow your instructions with a modest overclocking and a fast SSD. I thank you so much for your instructions and the time and effort you are spending for the community.
That sounds excellent! That’s a pretty respectable score. Those SanDisk Ultras really are good cards especially for how cheap they are! I’m surprised the performance isn’t a little better with that card as I do most of my testing on a Pi 400 with 4GB of RAM with the SanDisk Ultra SD card but to be fair the Pi 400 is clocked something like 300MHz higher which is substantial.
There’s no question though that a SSD is a different (and higher) class of performance than even the best and most expensive SD cards in the world by a factor of something like 3-4x for even a $20 SSD. It honestly improves the Pi experience no matter what you are doing / what services you are running and I think this will be worthwhile for you.
If you go to the pibenchmarks.com main page you will see that people with very cheap SSDs like older Samsung 860 2.5″ SATA drives, Kingston A400s, etc. that easily hit 5000-7000 points on the Pi. There’s really no need to go for NVMe on the Pi 4 as it is limited by the USB 3.0 bus so I would recommend for 90% of people to just get a cheap 2.5″/M.2 SATA SSD. NVMe becomes a lot more worth it with a Compute Module 4 but for most people this will not become relevant until the Pi 5 is my guess.
NVMe does still make a difference but the USB 3.0 bus caps out at something like 10,000-11,000 points before you need to start bypassing USB 3.0 to achieve a higher score. Given that the cheap drives I’ve been talking about can already hit 6000-8000 points it’s not really cost effective to chase the cap and some people have hit the 10-11k cap with 2.5″ and M.2 SATA drives.
Definitely stay tuned for my update I’ll be putting out sometime this summer (at least that’s my tentative goal, it’s really planned for August) that will use box64 for emulation. Box64 is able to use some native system calls instead of emulating everything so it speeds things up and that will help as well.
things have improved significantly thanks to your hints. The benchmark now shows the following:
Category Test Result
HDParm Disk Read 327.14 MB/s
HDParm Cached Disk Read 316.94 MB/s
DD Disk Write 125 MB/s
FIO 4k random read 17793 IOPS (71172 KB/s)
FIO 4k random write 11844 IOPS (47379 KB/s)
IOZone 4k read 33680 KB/s
IOZone 4k write 29672 KB/s
IOZone 4k random read 18338 KB/s
IOZone 4k random write 32107 KB/s
Score: 7753
Unfortunately the world still loads slow but a lot faster with the newly installed Samsung SSD. It still takes about 2 minutes and 40 seconds to join the server. I’ll use it anyway since nukkit for instance lacks of recieps. Hopefully my sons will accept it ;-). Thank you so much for your hard work to make using the Raspberry Pi as a server more user friendly. Highly appreciated. I’ll have a look at this page from time to time to watch your improvements.
Excellent, I’m glad you stopped by again! I actually tried again recently and mine was slower than 1.18 and previous versions had been. I honestly think it has got slower with the new features (definitely has happened in the past with new updates as well). In other words I think your performance is right where it should be because the CPU does seem to be bogging it down a bit more than it had in previous versions.
Box64 as the emulator is still planned and we’re now in August and I’ve been dramatically catching up on my publishing and have got a lot out over the couple of weeks. This is coming soon and I’d be really curious if once it drops over the next couple of weeks or so if you could try again and let me know how improved it is. Thanks for checking back, 7753 is an excellent score and I think your IO is looking fantastic and that it’s up to me now to get the last piece to where it needs to be at here. Thanks again and stay tuned!
Things seem to feel snappier (I’d long been told by people who tried Box64 with my otherwise unchanged scripts that it reduced a lot of bottlenecking and that seems to be the case).
Note that for it to make a difference you need to be running a 64 bit OS (Ubuntu and Raspberry Pi OS both have 64 bit versions).
A quick way to check this is if you do a:
uname -m
you should get aarch64 if you are on 64 bit. I’d be curious how it works for you!
I got the ethtool Hyper-V fix to persist across reboots on Ubuntu 20.04.
Assuming you have ethtool installed (apt install ethtool) you can add “offload-tx off” to your /etc/network/interfaces, and Ubuntu will automatically run the ethtool command when it ups the interface. For example, my /etc/network/interfaces section for eth0 now looks like this:
# The primary network interfaceauto eth0
iface eth0 inet static
address 192.168.1.5
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
offload-tx off
Hey bpsimons,
Perfect! That makes sense that it wouldn’t have persisted otherwise. That’s a neat /etc/network/interfaces trick. I’ve literally never seen anyone specify those parameters in that file for this. Very cool!
I will definitely add this into the documentation for sure!
Something to add to the “Troubleshooting Note – Hyper-V”
I was experiencing the Hyper-V issue where Minecraft could ping my Bedrock Server but couldn’t join it. I’m running your Bedrock scripts on an Ubuntu Gen 2 Hyper-V VM on Windows 10.
This command immediately fixed the issue for me:
ethtool -K eth0 tx offIt seems like TX Checksum Offloading might be where the bug in Hyper-V exists, so disabling it with the above command gets around the bug. Not sure whether this command will persist across a reboot, but it’s a super easy solution. Hopefully it helps others.
Hey bpsimons,
Excellent, thanks for leaving this! Previously we had no idea how to fix them. I just told people to turn it back to Gen1 and that got them working (but is technically more of a workaround, yours is an actual fix).
I’ll add this to the documentation as a (almost certainly better) solution as well!
how do you manage backups in the docker ?
Hey MC_DAVE,
Great question! The easiest way is to use the instructions to get to your server files. In there there is a “backups” folder. This will do a backup each time your server starts.
To restore these backups you would basically just uncompress them into your Docker volume’s folder. Hopefully that helps!
All glory to James
My build:
Dell Wyse 5070 Thin Client Install (Pentium)
Install Ubuntu Server 22.04 LTS on device including SSH (Named:wyseserver)
1. Use Putty from windows machine to connect to wyseserver
2. Install updates:
sudo apt update && sudo apt upgrade -y && sudo apt autoremove -y3. Reboot:
reboot4. Fix any issues with updates:
sudo apt --fix-broken install5. Install docker:
sudo curl -fsSL get.docker.com | sh6. Create volume for portainer (portainer pretty kewl but not required) :
docker volume create portainer_data7. Install portainer:
docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest8. Install NFS so I can access the data from my Windows computer (PS install the Service for NFS features on Windows machine and don’t forget to start the service when done):
sudo apt install nfs-kernel-server9. Enable the NFS Service to start when server starts:
sudo systemctl enable nfs-kernel-server.service10. Start the NFS Service:
sudo systemctl start nfs-kernel-server.service11. Make some directories for a few persisten volumes for the data for the docker containers (make as many as you need servers):
sudo mkdir -p /mnt/dvols/mcsvol01sudo mkdir -p /mnt/dvols/mcsvol02
sudo mkdir -p /mnt/dvols/mcsvol03
12. Give nobody and nogroup permissions to these folders:
sudo chown -R nobody:nogroup /mnt/dvols/mcsvol01sudo chown -R nobody:nogroup /mnt/dvols/mcsvol02
sudo chown -R nobody:nogroup /mnt/dvols/mcsvol03
13. Give read write permissions to these folders:
sudo chmod 777 /mnt/dvols/mcsvol01sudo chmod 777 /mnt/dvols/mcsvol02
sudo chmod 777 /mnt/dvols/mcsvol03
14. Now give access to a specific ip or range to these NFSs:
sudo nano /etc/exportsEnter the IP or Range or subnet of the machine that you use to access the NFS
/mnt/dvols/mcsvol01 192.168.0.0/24(rw,sync,no_subtree_check)/mnt/dvols/mcsvol02 192.168.0.0/24(rw,sync,no_subtree_check)
/mnt/dvols/mcsvol03 192.168.0.0/24(rw,sync,no_subtree_check)
15. Save the File: Ctrl+X,Y,Enter
16. Update the NFS Table:
sudo exportfs -a17. Restart the NFS SerVice:
sudo systemctl restart nfs-kernel-server18. Check the status of the service if you are so inclined (absolutely optional):
sudo -isystemctl status nfs-kernel-server
exit
19. Allow NFS through firewall from specific IP:
sudo ufw allow from 192.168.0.0/24 to any port nfs20. Create some persistent docker volumes and bind them to the folders we created earlier (make as many as you need servers):
docker volume create --driver local --opt type=none --opt o=bind --opt device=/mnt/dvols/mcsvol01 mcserver01voldocker volume create --driver local --opt type=none --opt o=bind --opt device=/mnt/dvols/mcsvol02 mcserver02vol
docker volume create --driver local --opt type=none --opt o=bind --opt device=/mnt/dvols/mcsvol03 mcserver03vol
21. Create the servers (again as many as you need) (my ports follow sequence 19 server# 2/3):
docker run -it -v mcserver01vol:/minecraft --name mcserver01 --restart=always -e NoScreen=Y -e TZ="Australia/Sydney" -p 19012:19012/udp -p 19012:19012 -p 19013:19013/udp -p 19013:19013 -e PortIPV4=19012 -e PortIPV6=19013 05jchambers/legendary-bedrock-container:latestdocker run -it -v mcserver02vol:/minecraft --name mcserver02 --restart=always -e NoScreen=Y -e TZ="Australia/Sydney" -p 19022:19022/udp -p 19022:19022 -p 19023:19023/udp -p 19023:19023 -e PortIPV4=19022 -e PortIPV6=19023 05jchambers/legendary-bedrock-container:latest
docker run -it -v mcserver03vol:/minecraft --name mcserver03 --restart=always -e NoScreen=Y -e TZ="Australia/Sydney" -p 19032:19032/udp -p 19032:19032 -p 19033:19033/udp -p 19033:19033 -e PortIPV4=19032 -e PortIPV6=19033 05jchambers/legendary-bedrock-container:latest
22. Going to stop the first server so I can copy in my worlds, edit properties, textures so on…:
docker stop mcserver0123. Make permissions nobody and nogroup so I can edit the contents:
sudo chown -R nobody:nogroup /mnt/dvols/mcsvol0124. Navigate to folder from my windows PC and do all changes I require.
\\wyseserver\mnt\dvols\mcsvol0125. Start Docker contrainer up again as complete with my changes (I’m assuming the fixpermissions.sh is run on startup James?):
docker start mcserver0126. Access the terminal of the docker container:
docker exec -it mcserver01 bash28. Run the fix permissions script if required (Again not sure if required James?)
cd scripts./fixpermissions.sh
29. Exit the docker container terminal safely:
Ctrl+P+QHey Justin,
Wow, that is a great and fully complete build, great work! Thanks for such a detailed writeup as well as you’ve really covered a lot of things here that are not in the documentation yet but that I’m sure many others will want to do. This is fantastic!
I can answer about the fixpermissions.sh script. It should run this itself every time the server starts but yes in this situation I would run it manually to be sure. Essentially any time you are moving files, creating new folders, or editing the server files the ownership of the files tends to get messed up. In other words if you edit and save the file as root or another user that user will own the files which will start to cause crashes in the Minecraft server. The fixpermissions.sh script prevents this by taking ownership by the user that is running the server basically so everything matches up how it should.
Thank you for writing this! It’s like a “big picture” guide that shows a lot of cool Docker features / options to manage the feature that are not in the main documentation. Enjoy and take care!
Hello James!
This Docker version worked really good! Thank you for this! 😀
However i noticed something that i couldn’t manage to figure out.
How do we access the terminal of the server itself?
I wanted to give character admin role by writing “/OP [name]”
But i can’t seem to figure out how and where to even start the server again after we reboot our Raspberry pi 🙁
Hey Moses,
Thanks for the kind words! That is an understandable question! So to start the container again you just run the same command again to start it. It should take you straight into the console when you start it and then you can type “op yourplayer” (leave the forward slash off) and that should take care of it for you!
If the Docker container is in the background you can use:
sudo docker container lsto see all the running containers and their IDs. We can then attach to them with:
sudo docker container attach yourcontaineridThat will take care of it even if it’s running in the background!
Hi again James!
Thank you i finally got it to work! 🙂
I can’t however connect to my server after I rebooted my Pi today. All i get is “Could not connect: Outdated Client!”
Do you know how we can fix this? 🙁
Hey Moses,
I’m glad you got it working! So for the updates basically it will update every time you restart the server. If it’s still saying outdated version that means that Microsoft hasn’t put the updated version on their web site yet (that’s where the script downloads the latest available version from).
If you think things might be stuck you can launch the container with the Clean=Y flag to make it redownload it but it won’t help if Microsoft hasn’t uploaded a new version. My guess is this is likely resolved by now or others would be here so I think a restart should take care of it!
Hello, I think what you’re doing is really cool and the fact that you somehow managed to make this work on ARM even though Microsoft didn’t make an Arm build of their own server software (kinda dumb considering you can host a world on an ARM device so it’s obviously possible, I’ve even installed lineage OS and tested Bedrock on this Pi, though the gpu didn’t like that very much). Unfortunately I’ve been having trouble whenever I try to run the server it comes up with some errors and then it says:
Unable to connect to update website (internet connection may be down). Skipping update ...Even though I can pull the latest version without issue. It then says “Starting Minecraft server…” and terminates instantly with no explanation. I noticed another commentor had this issue as well but you made an updated version to fix that issue and it worked for them, so I have no idea why it’s happening, unless it’s possibly a different problem causing the same outcome. I haven’t actually been able to start the server once, it’s done the same thing since I started following your tutorial. I tried apt update and apt upgrade to make sure everything was up to date as well, nothing changed.
On top of that, I am unable to access the docker volume as it supposedly doesn’t exist (sudo docker volume inspect minecraftbedrockserver returns /var/lib/docker/volumes/minecraftbedrockserver/_data as the Mount point) and the /var/lib/docker folder is empty and is 0 bytes in size so there doesn’t seem to be anything in it.
Using a Raspberry Pi 4, 4gb with 32-bit version of Raspberry Pi OS
Screenshot of output from command line.
Output copied from commandline:
pi@raspberrypi:~ $ sudo docker run -it -v minecraftbedrockserver:/minecraft -p 19132:19132/udp -p 19132:19132 05jchambers/legendary-bedrock-container:latestMinecraft Bedrock Server Docker script by James A. Chambers
Latest version always at https://github.com/TheRemote/Legendary-Bedrock-Container
Don't forget to set up port forwarding on your router! The default port is 19132
Ports used - IPV4: 19132 - IPV6: 19133
sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit
Checking for the latest version of Minecraft Bedrock server ...
Unable to connect to update website (internet connection may be down). Skipping update ...
Starting Minecraft server...
[screen is terminating]
pi@raspberrypi:~ $ sudo docker pull 05jchambers/legendary-bedrock-container:latest
latest: Pulling from 05jchambers/legendary-bedrock-container
Status: Image is up to date for 05jchambers/legendary-bedrock-container:latest
docker.io/05jchambers/legendary-bedrock-container:latest
pi@raspberrypi:~ $ sudo docker run -it -v minecraftbedrockserver:/minecraft -p 19132:19132/udp -p 19132:19132 05jchambers/legendary-bedrock-container:latest
Minecraft Bedrock Server Docker script by James A. Chambers
Latest version always at https://github.com/TheRemote/Legendary-Bedrock-Container
Don't forget to set up port forwarding on your router! The default port is 19132
Ports used - IPV4: 19132 - IPV6: 19133
sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit
Checking for the latest version of Minecraft Bedrock server ...
Unable to connect to update website (internet connection may be down). Skipping update ...
Starting Minecraft server...
[screen is terminating]
Hey Sudîmia,
Welcome! I think I can help. The problem is this:
sudo: unable to get time of day: Operation not permittedsudo: error initializing audit plugin sudoers_audit
It looks like this is a problem with DNS resolution in your Docker environment. I found something here.
I noticed several people in there said that the person had an older Debian Buster install installed. This is extremely common since if you didn’t image your Pi after April 2022 you also have Buster instead of Bullseye which is the latest one. Unfortunately not even a sudo apt-get dist-upgrade will upgrade you to a new release (more on this in a moment).
The reason the volume is empty is because it actually can’t download the bedrock_server. There’s nothing to unzip basically. That is from this message you mentioned:
Unable to connect to update website (internet connection may be down). Skipping update ...Basically because it can’t resolve the DNS name of the web site it actually can’t download the server from Microsoft if that makes sense.
I think updating the Pi to Bullseye should do it. The fastest way to do it is to just reimage it with the latest Bullseye OS (available in the Pi Imager and from the Downloads section) but it’s possible to upgrade it.
It takes about 5 times longer to upgrade it than to reimage it and there’s a lot of steps and issues to watch out for so I highly recommend doing a fresh install of Bullseye. If there’s a lot of other stuff or configuration done on the Pi though an upgrade is possible (do backups first). I highly, highly recommend the 64 bit version of Bullseye. It will be much, much slower in 32 bit because it can’t use Box64. It’s honestly a perfect chance to reimage it with a 64 bit OS. It’s nearly unplayable in 32 bit (although some people still run it on there and it’s fast enough for them but I would say it’s too slow).
There’s another option as well. You can actually run a Java server that Bedrock and Java players can both connect to using this version of the container: Minecraft Java + Bedrock Together: Geyser + Floodgate. This will be fast on 32 bit although the Docker will probably still have that same DNS issue without an upgrade to Bullseye.
Bullseye should for sure take care of the Docker issues for you!
Wow that was fast! Thank you, that makes sense because this pi had been unused for about a year. Will reimage it with the 64-bit version of Bullseye and get back to you in case it might help someone else with the same issue.
Hey Sudîmia,
No problem at all, thank you for asking this as I don’t think it has come up in this article at all (the container is still relatively new) and I’m certain it will help others as well.
I’m not sure I’ve seen that specific error message ever before either as I had to do some research on that one. The Bullseye vs Buster fix has come up before on the standalone container but with totally different errors/symptoms. Your post is the first documentation of this issue on Docker that I have and I appreciate you giving such thorough logs (that definitely helped me diagnose it as far as I was able to for sure).
Definitely feel free to stop stop by if you run into any issues and enjoy!
So I reimaged the Pi with Bullseye 64-bit and re-did everything from scratch including a mumble server and smb server, as well as installing box64, and then set up your docker container. I got no errors and was able to join without issue. The first join took about a minute or two (pi was generating the nearby chunks) everything seemed normal, there were animals as well. After the initial generation it took about 30-45 seconds to join.
I didn’t notice much lag though the first command entered on either the server CLI or on an operator client seems to always produce a giant lag spike and everything in the game freezes for about 30-60 seconds and then it’s suddenly fine. Teleporting to unloaded chunks seems to do the same thing as well, though I didn’t do a lot of testing. I do believe most of the problems can be a attributed to lack of an SSD or other decent storage options, current storage is a 200gb micro SD card. I imported a creative world to the docker volume and used that for the server and noticed some lag with pressure plates connected to iron doors and would end up walking into the door before it opened.
Planning on using a faster storage option in the future, though I’m not sure how I would move a docker volume to a different drive it’s probably pretty easy. This seems like a viable solution and would work fine for a dedicated Bedrock server when using a faster storage device. Amazing work!
Hey Sudîmia,
Congratulations and excellent work! You’re 100% right about all of your observations here. The delays you are observing from joining and teleporting/going to unloaded chunks are storage bottlenecking. The SSD does an amazing job dramatically reducing those times.
For moving the Docker contents to a different volume if you use sudo you can navigate to the Docker volume contents as just a hard drive folder (see the accessing files section for more on this, there’s a command you can use to get the exact folder on the drive listed there). Essentially you can copy them and create a new Docker volume on the host with docker volume create yourvolume. That would give you an empty folder to copy the files into from the old server/system.
Thanks for sharing a detailed account of your experience, I’d love to hear how it goes if you are able to test it with a SSD as well in the future. Take care!
Hey James,
at first I’d like to thank you to make it so easy to set up a minecraft server on a raspberry for us! Great work. But I still run into a bit of trouble. I am using a Raspberry Pi 4 with 4 GB of ram and a Raspberry Pi OS (64 bit). The Server starts perfectly fine and delivers the following output:
[2022-07-21 14:49:31] NO LOG FILE! - setting up server logging...[2022-07-21 14:49:31] [2022-07-21 14:49:31:612 INFO] Starting Server
[2022-07-21 14:49:31] [2022-07-21 14:49:31:616 INFO] Version 1.19.10.03
[2022-07-21 14:49:31] [2022-07-21 14:49:31:616 INFO] Session ID 779e793e-60db-408f-a088-9e9bf9d4c61e
[2022-07-21 14:49:31] [2022-07-21 14:49:31:655 INFO] Level Name: Bedrock level
[2022-07-21 14:49:32] [2022-07-21 14:49:32:710 INFO] Game mode: 0 Survival
[2022-07-21 14:49:32] [2022-07-21 14:49:32:711 INFO] Difficulty: 1 EASY
[2022-07-21 14:49:33] [2022-07-21 14:49:33:119 INFO] opening worlds/Bedrock level/db
[2022-07-21 14:50:05] [2022-07-21 14:50:05:540 INFO] IPv4 supported, port: 19132
[2022-07-21 14:50:05] [2022-07-21 14:50:05:550 INFO] IPv6 not supported
[2022-07-21 14:50:15] [2022-07-21 14:50:15:798 INFO] Server started.
[2022-07-21 14:50:15] [2022-07-21 14:50:15:858 INFO] ================ TELEMETRY MESSAGE ===================
[2022-07-21 14:50:15] [2022-07-21 14:50:15:858 INFO] Server Telemetry is currently not enabled.
[2022-07-21 14:50:15] [2022-07-21 14:50:15:859 INFO] Enabling this telemetry helps us improve the game.
[2022-07-21 14:50:15] [2022-07-21 14:50:15:860 INFO]
[2022-07-21 14:50:15] [2022-07-21 14:50:15:863 INFO] To enable this feature, add the line 'emit-server-telemetry=true'
[2022-07-21 14:50:15] [2022-07-21 14:50:15:864 INFO] to the server.properties file in the handheld/src-server directory
[2022-07-21 14:50:15] [2022-07-21 14:50:15:866 INFO] ======================================================
[2022-07-21 14:50:15] [2022-07-21 14:50:15:013 INFO] IPv4 supported, port: 46660
[2022-07-21 14:50:15] [2022-07-21 14:50:15:013 INFO] IPv6 not supported
[2022-07-21 14:50:31] [2022-07-21 14:50:31:429 INFO] Player connected: XXXXX, xuid: 2535450906092014
I am using a Huwai MediaPad M5 lite 10 with Android 8 and Minecraft 1.19.10 to connect to the server. When connecting it gets stuck at “searching for server” for 2 minutes and 50 seconds until I join the game. The game than starts in an ice biome and works fine at the spawning point. But when I walk away a few chunks the next chunks just won’t load. I am trapped in quite a tiny world. Is there any known reason why it takes so long to join the world or why it is not loading within an acceptable amount of time?
Any hint is appreciated. My boys would love to play on this server 😉
I thank you for your efforts in advance.
Kind regards
Kerzenmeister from Germany
Hey Kerzenmeister,
Welcome! I definitely think I can help explain some of what is going on. There are basically two bottlenecks to worry about with the Minecraft server on the Pi. That is basically CPU and your storage device.
It’s pretty common on a Pi to be using a micro SD card as that is the standard. The problem with Minecraft is when you are moving throughout chunks if you’ve never been to those chunks before such as on a new server they have to be completely generated from scratch and then written to storage. The SD card definitely struggles to keep up and that is most of what you are waiting for.
The other bottleneck is the CPU. This is because the Bedrock server isn’t actually available in ARM so I’m “cheating” to run it by using QEMU which is a layer of emulation. I have plans to integrate Box64 into the container sometime this summer which will improve this. Mild overclocks on the Pi can actually help as well with the CPU part of this. Note that the CPU doesn’t explain the level of bottlenecking you are experiencing unless you are running other services on the Pi at the same time. The CPU is the same in the 1GB/2GB/4GB/8GB models and it will *not* bottleneck it to this extent unless it’s competing with something else (at least on the Pi 4).
With all that said from what you’re saying yours sounds a little bit on the slower side to me and I would bet that it’s not using a SSD. It’s definitely not perfect even on a SSD and you’ll experience effects like sometimes you’ll break a block and there will be a slight delay before picking it up. It’s actually playable though and yours sounds like it’s unplayable at the moment. There may be some chunk lag but nothing that would ever trap you in an area like this. It’s actually playable and yours sounds like it’s pretty much unplayable at the moment. High quality SD cards would typically also not bottleneck to this extent and a lot of my testing is done on SD cards (that’s what my Pi 400 is using right now, SanDisk Ultra A1 SD card).
I’ve covered how to upgrade to an SSD for (relatively) cheap (something like a $15 USB to SATA adapter and a Kingston A400 can be had for ~$20 as well) in this guide here.
I would strongly recommend running my storage benchmark from pibenchmarks.com. This will give us an idea of how your disk is performing. This can be done with:
https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bashThe average score for a SD card is probably something like around 1000 and for a SSD anywhere from 5000-8000. There are definitely SD cards out there such as cards without application class (A1 or A2) that may perform substantially worse and get something like 600-700 points and I wonder if yours will be like that with the intensity of the bottlenecking your are experiencing.
Unfortunately the cost of the SD card doesn’t necessarily always reflect the performance. It may have not been a cheap SD card but if it’s missing a few key things like being application class the performance might literally be 50% of what something like a cheap SanDisk Ultra that does have the A1 classification can perform (and the bottlenecking would roughly be 50% improved in this theoretical scenario because the Pi is just waiting on the disk due to the bottlenecking so you would feel every % point of a 50% improvement in disk performance). I made the storage benchmark at pibenchmarks.com years ago to solve this very question (and it was actually Minecraft that drove me making it in the first place as it makes such a huge difference which SD card you have).
You can actually do some tests on your Pi to confirm the bottlenecks. Running “top” will let you see the CPU usage and “iotop” for disk usage. These are the two factors somewhat in your control via overclocking for the CPU and using something like a SSD (or application class A1/A2 SD cards) for the disk. Hopefully that helps!
Thank you so much James,
I benchmarked my Sandisk Ultra with a score of 1352. I will certainly follow your instructions with a modest overclocking and a fast SSD. I thank you so much for your instructions and the time and effort you are spending for the community.
Kind regards
Kerzenmeister
Hey Kerzenmeister,
That sounds excellent! That’s a pretty respectable score. Those SanDisk Ultras really are good cards especially for how cheap they are! I’m surprised the performance isn’t a little better with that card as I do most of my testing on a Pi 400 with 4GB of RAM with the SanDisk Ultra SD card but to be fair the Pi 400 is clocked something like 300MHz higher which is substantial.
There’s no question though that a SSD is a different (and higher) class of performance than even the best and most expensive SD cards in the world by a factor of something like 3-4x for even a $20 SSD. It honestly improves the Pi experience no matter what you are doing / what services you are running and I think this will be worthwhile for you.
If you go to the pibenchmarks.com main page you will see that people with very cheap SSDs like older Samsung 860 2.5″ SATA drives, Kingston A400s, etc. that easily hit 5000-7000 points on the Pi. There’s really no need to go for NVMe on the Pi 4 as it is limited by the USB 3.0 bus so I would recommend for 90% of people to just get a cheap 2.5″/M.2 SATA SSD. NVMe becomes a lot more worth it with a Compute Module 4 but for most people this will not become relevant until the Pi 5 is my guess.
NVMe does still make a difference but the USB 3.0 bus caps out at something like 10,000-11,000 points before you need to start bypassing USB 3.0 to achieve a higher score. Given that the cheap drives I’ve been talking about can already hit 6000-8000 points it’s not really cost effective to chase the cap and some people have hit the 10-11k cap with 2.5″ and M.2 SATA drives.
Definitely stay tuned for my update I’ll be putting out sometime this summer (at least that’s my tentative goal, it’s really planned for August) that will use box64 for emulation. Box64 is able to use some native system calls instead of emulating everything so it speeds things up and that will help as well.
Thanks for the kind words, take care and enjoy!
Hello James,
things have improved significantly thanks to your hints. The benchmark now shows the following:
Category Test ResultHDParm Disk Read 327.14 MB/s
HDParm Cached Disk Read 316.94 MB/s
DD Disk Write 125 MB/s
FIO 4k random read 17793 IOPS (71172 KB/s)
FIO 4k random write 11844 IOPS (47379 KB/s)
IOZone 4k read 33680 KB/s
IOZone 4k write 29672 KB/s
IOZone 4k random read 18338 KB/s
IOZone 4k random write 32107 KB/s
Score: 7753
Unfortunately the world still loads slow but a lot faster with the newly installed Samsung SSD. It still takes about 2 minutes and 40 seconds to join the server. I’ll use it anyway since nukkit for instance lacks of recieps. Hopefully my sons will accept it ;-). Thank you so much for your hard work to make using the Raspberry Pi as a server more user friendly. Highly appreciated. I’ll have a look at this page from time to time to watch your improvements.
Kind regards from Germany
Kerzenmeister
Hey kerzenmeister,
Excellent, I’m glad you stopped by again! I actually tried again recently and mine was slower than 1.18 and previous versions had been. I honestly think it has got slower with the new features (definitely has happened in the past with new updates as well). In other words I think your performance is right where it should be because the CPU does seem to be bogging it down a bit more than it had in previous versions.
Box64 as the emulator is still planned and we’re now in August and I’ve been dramatically catching up on my publishing and have got a lot out over the couple of weeks. This is coming soon and I’d be really curious if once it drops over the next couple of weeks or so if you could try again and let me know how improved it is. Thanks for checking back, 7753 is an excellent score and I think your IO is looking fantastic and that it’s up to me now to get the last piece to where it needs to be at here. Thanks again and stay tuned!
UPDATE: I actually finished this today! It is now live on the latest image if you do a:
docker pull 05jchambers/legendary-bedrock-container:latestThings seem to feel snappier (I’d long been told by people who tried Box64 with my otherwise unchanged scripts that it reduced a lot of bottlenecking and that seems to be the case).
Note that for it to make a difference you need to be running a 64 bit OS (Ubuntu and Raspberry Pi OS both have 64 bit versions).
A quick way to check this is if you do a:
uname -myou should get aarch64 if you are on 64 bit. I’d be curious how it works for you!