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!
This is based off my Minecraft Bedrock Linux Dedicated Server scripts for Linux project. I’m going to release a version for the Java Minecraft edition as well so stay tuned for that.
The official GitHub repository is located here.
The official Docker Hub repository is located here.
If you are looking for the Java version of the Docker container it is located here. This is for the Bedrock edition of Minecraft.
You can also run my Geyser + Floodgate Java Minecraft Server container and Bedrock players will be able to connect to it!
It’s now possible to convert your worlds between Bedrock and Java versions. Check out my guide on Chunker here for more information.
Features
- 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.
With default ports:
docker run -it -v yourvolumename:/minecraft -p 19132:19132/udp -p 19132:19132 -p 19133:19133/udp -p 19133:19133 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
With custom ports:
docker run -it -v yourvolumename:/minecraft -p 12345:12345/udp -p 12345:12345 -p 12346:12346/udp -p 12346:12346 -e PortIPV4=12345 -e PortIPV6=12346 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
IPV4 only:
docker run -it -v yourvolumename:/minecraft -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
Configuration / Accessing Server Files
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:
{ "CreatedAt": "2022-05-09T21:08:34-06:00", "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/yourvolumename/_data", "Name": "yourvolumename", "Options": {}, "Scope": "local" }
On Linux it’s typically available at:
/var/lib/docker/volumes/yourvolumename/_data
On Windows it’s at
C:\ProgramData\DockerDesktop
but may be located at something more like
\wsl$\docker-desktop-data\version-pack-data\community\docker\volumes\
if you are using WSL (Windows Subsystem for Linux).
On Mac it’s typically
~/Library/Containers/com.docker.docker/Data/vms/0/
If you are using Docker Desktop on Mac then you need to access the Docker VM with the following command first:
screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty
You can then normally access the Docker volumes using the path you found in the first step with docker volume inspect
Most people will want to edit server.properties. You can make the changes to the file and then restart the container to make them effective.
Backups are stored in the “backups” folder
Log files with timestamps are stored in the “logs” folder.
Version Override
In some scenarios you may want to run a specific version of the Bedrock server. That is now possible by using the “Version” environment variable:
-e Version=1.18.33.02
For example:
docker run -it -v yourvolumename:/minecraft -e Version=1.18.33.02 -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
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:
docker run -it -v yourvolumename:/minecraft -e Clean=Y -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
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:
-e UseQEMU=Y
For example:
docker run -it -v yourvolumename:/minecraft -e UseQEMU=Y -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
TZ (timezone) Environment Variable
You can change the timezone from the default “America/Denver” to own timezone using this environment variable:
docker run -it -v yourvolumename:/minecraft -e TZ="America/Denver" -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
A list of Linux timezones is available here.
NoPermCheck Environment Variable
You can skip the permissions check (can be slow on very large servers) with the NoPermCheck environment variable:
docker run -it -v yourvolumename:/minecraft -e NoPermCheck="Y" -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
Troubleshooting Note – Oracle Virtual Machines
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!
Hi… after setting up docker and running your script, terminal returns “Starting Minecraft Server” and then immediately terminates the screen session. Not certain what I am doing wrong.
This is a VM on Oracle running Ubuntu 20.04.
Hey Topher M,
I’m investigating now and I think Microsoft changed the dependencies in the newer version.
Old version linking (1.18.33.02):
james@jamesgigabyte-linux:~/minecraftbe/james/downloads$ ldd bedrock_server
linux-vdso.so.1 (0x00007ffd62dfb000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56e7f30000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f56e7f14000)
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f56e7e7c000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f56e7ba1000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f56e7b9c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f56e7b95000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f56e7aae000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f56e7aa9000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f56e787d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f56e785d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f56e7635000)
/lib64/ld-linux-x86-64.so.2 (0x00007f56e7f6d000)
New version linking (1.19.10 – unofficial codename “libssl linking hell version”):
james@jamesgigabyte-linux:~/minecraftbe/james$ ldd bedrock_server
linux-vdso.so.1 (0x00007ffd075c6000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f6c4f858000)
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f6c4f7c0000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f6c4f4e5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6c4f4e0000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6c4f4db000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6c4f3f2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6c4f3ed000)
libcurl.so.4 => /lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f6c4f347000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6c4f11b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6c4f0fb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6c4eed3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6c4f895000)
libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f6c4eea7000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f6c4ee86000)
librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f6c4ee67000)
libssh.so.4 => /lib/x86_64-linux-gnu/libssh.so.4 (0x00007f6c4edfa000)
libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f6c4ede6000)
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f6c4ed42000)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f6c4e8fe000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f6c4e8aa000)
libldap-2.5.so.0 => /lib/x86_64-linux-gnu/libldap-2.5.so.0 (0x00007f6c4e84b000)
liblber-2.5.so.0 => /lib/x86_64-linux-gnu/liblber-2.5.so.0 (0x00007f6c4e83a000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f6c4e76b000)
libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f6c4e75d000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6c4e73f000)
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f6c4e595000)
libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f6c4e3aa000)
libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007f6c4e362000)
libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x00007f6c4e31c000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f6c4e298000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f6c4e1cd000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f6c4e19e000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f6c4e198000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f6c4e18a000)
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f6c4e16d000)
libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f6c4e14a000)
libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f6c4e00f000)
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f6c4dff7000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f6c4dff0000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f6c4dfda000)
libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007f6c4dfcd000)
My goodness, there are literally like 3x as many linked dependencies, what a mess! I think this is the culprit:
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f6c4ed42000)
It looks like it’s time to move to libssl3 because the new version seems to be linking against that (along with a bunch of other new dependencies, any one of these which could explain this).
I’ll get some updates going here!
Ah ok, well I didn’t intend to create more work for you, but I (and my minecrafting nephews) thank you for the work you do and the generosity with which you offer it to the internet!
Hey Topher,
No worries at all! I actually got posts about this all over the site and on GitHub (there were like 2-3 between 8-11PM). I have an updated build with these new dependencies building now that should be live in about 15 minutes or so.
You can pull the latest then with:
docker pull 05jchambers/legendary-bedrock-container:latest
and let’s see if that can get it going here!
I got it working! Takes a few minutes to connect, but seems to ruin smoothly otherwise. Thank you very much!
Hey Topher,
Excellent, thank you for letting me know! I do have some box64 emulator plans to help speed up aarch64 here but I definitely wanted to get it working again for this new version before pushing harder for something new. Thanks again and take care!
I have followed the instructions, I believe, but don’t seem to get the server to restart when I reboot (I tried to reboot the machine to pick up new server.properties changes).
I also don’t appear to have any containers within docker (docker container ls) and found my docker volumes in /var/snap/docker/common/var-lib-docker/volumes/minecraft1/_data. Does this suggest I did something wrong?
Also interested in running multiple instances for different worlds… any hints? (First time with docker- can you tell?!)
Hey Tfes,
Welcome, I think I can help! So the Docker volume path looks totally okay. This is just in a different place than my examples because it was installed through snap instead of apt but it is totally fine so this piece is okay.
For the containers restarting with the machine this is normal as Docker doesn’t typically do this automatically. There are a few ways to do it. I have an example docker-compose.yml file in the repository for this that is really good for automation.
Here’s an example of one way to set this up. You could basically add the –restart always flag to the container when you launch it.
Docker-compose seems to be the most elegant way to do this that I’ve found. We’ve had some others use this already here in the comments for sure. To do this you would install docker-compose and then you can use the .yml file in the repository to make templates to configure the different services. I’d never touched docker-compose in my entire life until about a week or two ago when it came to my attention that this was an issue and once I tried it I thought it was really nice/easy. Once you set up the files you basically install the service and then bringing them up is as easy as
docker-compose up
or completely automatic depending on how you configure it.That leads into your last question which is multiple instances of different worlds. This is absolutely supported! There is one key part to doing this. You must choose completely different ports for each server. In the examples I show how to do this and basically you just need to make sure none of the ports overlap. They also each need their own volume (to store the different worlds).
That’s all there is to it basically. The docker-compose.yml file makes this much easier to manage as you can specify the individual volume name and ports for each world right in those files so you don’t have to have a bunch of different messy launch lines.
Hopefully that helps and let me know if I can help further!
I am having an issue where the server changes port first it goes to the correct port but then it changes port also it appears not to want to use IPv6
Logs:
minecraftbe [2022-07-03 07:31:06] [2022-07-03 07:31:06:844 INFO] IPv4 supported, port: 19132
minecraftbe [2022-07-03 07:31:06] [2022-07-03 07:31:06:859 INFO] IPv6 not supported
minecraftbe [2022-07-03 07:31:14] [2022-07-03 07:31:14:471 INFO] IPv4 supported, port: 50093
minecraftbe [2022-07-03 07:31:14] [2022-07-03 07:31:14:472 INFO] IPv6 not supported
Hey SolarSciencePup,
Oh wow, those are two pretty good issues that haven’t come up much for the container yet! So the second set of ports is a bug. Microsoft introduced this bug in something like 2018 to the Bedrock server and I guarantee it will never be fixed at this point as it has been 4+ years. You can safely ignore the second port (it won’t do anything). No matter what script/version you use you will have this bug and there’s no escaping it unfortunately but it doesn’t seem to really do anything except screw up the default ports completely in rare cases where they have to use 0 of the default ports. Here’s some references:
Reference #1
Reference #2
Now let’s talk about the IPV6 ports. This is the Docker default configuration basically and IPV6 is disabled by default. Here’s how to turn it on (it’s very easy).
or basically:
That should take care of it and enable IPV6 for you!
Thanks!
A truly awesome article, dockerizing the server is a great idea. It sucks that Microsoft doesn’t support ARM.
Similar to Dea7h, I am having an issue loading into the server once I get it running. I get stuck on “Locating server…” for quite some time, then once I get into the server, the performance is dreadful.
I have Ubuntu 22. 64bit loaded up on a 4GB Raspberry Pi 4. Any performance tips?
Hey BlueFrog,
Thanks for stopping by and the kind words! The biggest one for sure is a SSD. This is a huge performance upgrade all around for the Pi. If you aren’t already using one that’s for sure the place to start. I do have a guide on this available here as well.
You have 64 bit already so that is a good performance improvement box you’ve already checked here. It sounds a little bit on the slow side so I’m suspecting there may not be a SSD (or it may not be performing quite up to par, my pibenchmarks.com site can help test this). It could be because my Pi is the 8GB model but this one sounds like it’s chugging more than others to me.
I think your “Locating Server” issue is different from the other person’s here as my understanding was that it never went away for them. It’s possible though that their performance was so bad they never got in. I actually hadn’t really considered that but I’m sure there’s Pis already running existing services out there and ones that are 1GB models and things like that that could easily perform bad enough that it seems like forever (or it hits every possible timeout before it connects). That is way, way slower than most people’s experience though especially on a SSD.
There’s things I can do to optimize it but they’re quite difficult. I can use the Box64 emulator which can turn some of the syscalls that are currently being emulated into native calls but there is no such thing as a static Box64 build meaning I will have to build the entire box64 project in the container. This is on my to-do list and should enhance the container performance on aarch64 significantly (in theory, and on my standalone project people have tried this and it did make a significant difference).
The biggest one I would say for sure that is in your control is to use a good and preferably NVMe SSD (but a 2.5″ SATA one is still pretty decent). My pibenchmarks.com benchmark can definitely give you an idea of how much improvement you can gain from this and what to expect. There are tens of thousands of existing benchmarks so it’s extremely likely there are already other benchmarks on there you can compare to get an idea. The SSD is worthwhile to do no matter what (box64 or no box64) and you’ll see they outperform even the best SD cards by a factor of 6x-7x or so!
Definitely stay tuned for the box64 updates to the container. I’m kind of in “publishing mode” right now where I need to catch up on my blog posts (after an extended period of “project mode” making this container and the Paper one) and you can see in my “Recent Posts” there was a big publishing gap. Basically once I get a few more articles out and “catch up” this is on my to-do list to get this functioning (or at least available as a “beta” flag in the container to use for people who want to try it).
Hopefully that helps!
Things you might want to mention above… or just allow people to scroll down to the comments. 😉
* It took me *ages* to fix my docker containers failing to connect to the internet [1]. Fixed by setting “date” properly [2].
* The Docker instructions for how to magically “–restart” your containers [3]. I go with “always”, then “update” when I need to bring it down for maintenance.
However, I’m still getting “Locating server…” issues, possibly the same as what Ishann [4] did. It’s an RPi4, probably using a default memory split. Not sure what I need to fix/tweak/update. I’ll start with the OS… I think I’m running an old 32-bit Raspbian.
[1] reddit
[2] docs.linuxserver.io
[3] docs.docker.com
[4] James A. Chambers Minecraft Bedrock Server
Get Dea7h,
Great information / diagnosing here. I’ve actually never heard of the date issue! I bet that will help some others that arrive here in Google or otherwise. I’ll definitely want to get this added into the main documentation as well. I’m kind of gauging that based on what comes up here in the comments and you’re right that this should go into the documentation for sure.
One thing to keep in mind with the automatic starting is that I have a default docker-compose.yml that shows the proper options to use. Basically if it’s being launched automated it still needs to be run with docker -it. For docker-compose this looks like:
stdin_open: true # docker run -i
tty: true # docker run -t
Are you able to attach to the server console? You should be able to see it running and that definitely helps narrow things down a little bit.
I think that going to the latest Raspberry Pi OS will probably get it for you. I highly recommend the 64 bit version (I have a guide on where to get this here). This is mostly for performance reasons (some emulation is used on ARM and and it’s a little bit easier to go from 64 bit to 64 bit instead of adding a 32 bit translation layer on top of it). It can absolutely do it though on either 32 bit or 64 bit.
I think the date needing to be set like that may be a hint that this Pi would benefit a lot from a refresh to the latest. We have seen some similar issues before recently that were fixed by going to Bullseye.
This reminds me a lot of an issue that came up on GitHub not too long ago. The way you are talking about starting the container automatically makes me wonder if it’s related to not having an interactive terminal. This is usually easily fixed through configuration like the docker-compose ones I mentioned earlier and the other automatic launch methods should have a similar option. Here is the GitHub issue.
Definitely let us know how it goes and I will definitely try to help where I can if anything strange comes up!
This container is truly awesome. Currently I am having issues with the docker container exiting and Ubuntu crashing with disk errors (on an SDD). Is the best course to simply copy the world and reimage the machine with 22.04 (what we are currently running)?
Such a simple thing, I am amazed that the whole machine is so unstable. I’m running this server on a laptop with nothing else running that I built just for this.
Hey Firebourne,
That’s probably what I would do. If it keeps happening it’s probably indicating some kind of problem either with drivers/firmware or the disk itself. I think reimaging is where to start and see if you can get this to stop happening (otherwise it indicates a deeper problem).
I’m glad you’re enjoying it! I think that is definitely the best course of action as I’ve fought with trying to fix these before and it’s just never almost worth it vs. doing a rebuild. Hopefully that helps!
I followed the installation steps on oracle cloud VPS, but I cannot connect to the server. I’ve allowed traffic from both ports in oracle and ubuntu 20.04 VM(ufw)
CPU – Ampeare, ARM64. RAM – 6gb.
Hey Rajdeep,
The Oracle VM is pretty notorious around here. It hasn’t come up yet for the container but it comes up *a lot*. Check out this thread here.
The answer to fixing this:
Basically it works fine but Oracle has additional security settings that I don’t think anyone has ever got on the first try. Specifically you are looking for the “Virtual Cloud Network” settings where you will set the ingress ports *AND* you have to create a network security group and assign/attach it to your instance and also do the ingress ports there.
I’ve never seen a more difficult VM to configure than Oracles but people love it once it’s configured. I personally use Amazon Lightsail and have to do literally none of this other than add the port to Amazon’s incredibly simple firewall settings. The Oracle VM configuration is significantly harder and more advanced than any other system I’ve seen but people do like it once it’s going for sure.
Hopefully that helps!