Minecraft Java + Bedrock Server Together – Geyser + Floodgate

Hey Mitsch,

Don’t sweat it at all! I hope my frustration didn’t come off as directed at you guys. It’s really not at all and has more to do with how the forked Minecraft server ecosystem works where there is this small gap in time between updates where there’s this sticking point. Many of you are frustrated with it like I am when it takes a lot longer than usual and things start breaking like this (albeit temporarily). It puts both server operators and projects like mine that are downstream in a difficult position where all we can do is wait (and I do hate waiting).

The Geyser message does seem to be misleading since it is talking about the Java version but the Java version is just OpenJDK 19 (the current release). It’s hard to say if this is related to the Minecraft Bedrock clients being too new for Geyser to handle or if they changed something for the new update that actually broke the old version.

Definitely let me know what you find if you run this experiment since I’m actually not sure what you will find. If the new Bedrock client is the problem (and Geyser just isn’t handling it correctly yet) then rolling back to an older Geyser won’t fix it. If this is a breaking change they introduced in the new Geyser it will 100% fix it. What you find may impact what I do with the container as well so if you get a chance let me know!

Hey Dylan,

Excellent, I’m glad it’s working! Honestly you don’t need to memorize anything. Just type “docker”. It will tell you everything (including what the commands do) and that is what I do:

Management Commands:
builder Manage builds
config Manage Docker configs
container Manage containers
context Manage contexts
image Manage images
manifest Manage Docker image manifests and manifest lists
network Manage networks
node Manage Swarm nodes
plugin Manage plugins
secret Manage Docker secrets
service Manage services
stack Manage Docker stacks
swarm Manage Swarm
system Manage Docker
trust Manage trust on Docker images
volume Manage volumes

Commands:
attach Attach local standard input, output, and error streams to a running container
build Build an image from a Dockerfile
commit Create a new image from a container's changes
cp Copy files/folders between a container and the local filesystem
create Create a new container
diff Inspect changes to files or directories on a container's filesystem
events Get real time events from the server
exec Run a command in a running container
export Export a container's filesystem as a tar archive
history Show the history of an image
images List images
import Import the contents from a tarball to create a filesystem image
info Display system-wide information
inspect Return low-level information on Docker objects
kill Kill one or more running containers
load Load an image from a tar archive or STDIN
login Log in to a Docker registry
logout Log out from a Docker registry
logs Fetch the logs of a container
pause Pause all processes within one or more containers
port List port mappings or a specific mapping for the container
ps List containers
pull Pull an image or a repository from a registry
push Push an image or a repository to a registry
rename Rename a container
restart Restart one or more containers
rm Remove one or more containers
rmi Remove one or more images
run Run a command in a new container
save Save one or more images to a tar archive (streamed to STDOUT by default)
search Search the Docker Hub for images
start Start one or more stopped containers
stats Display a live stream of container(s) resource usage statistics
stop Stop one or more running containers
tag Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
top Display the running processes of a container
unpause Unpause all processes within one or more containers
update Update configuration of one or more containers
version Show the Docker version information
wait Block until one or more containers stop, then print their exit codes

You don’t need to memorize everything as that is a waste of brain space (there’s over 50+ just base commands). In other words it’s far more important to learn to find any command you want whenever you want than it is to physically memorize every single command. It will all probably be different in 5-10 years anyway (if you look at the “docker” command from 5-10 years ago half the things on that list won’t exist, and another 5 to 10 years from now the current list will look like a joke compared to the one then). I tend to work with all of my systems this way / with this mentality.

How can one memorize a dozen different programming languages? How can a tech remember everything for a thousand systems they cover? You don’t. Once you get to that point memorization won’t help you. It’s about whether you have enough of a understanding and the proper tools to solve the problems (even if nobody has ever seen them before, which will be the case much of the time).

When I’m working with professional IT techs or engineers the dividing lines tend to be along who can teach themselves to think / work this way. Some people are really good at memorizing things and can be great experienced techs/engineers. They’ve seen it all before, they know everything off the top of their head, that kind of thing. Those are never the people that make it to the top / leadership positions though. It’s the people who can learn to solve any problem (especially the ones nobody has seen before). At that level it becomes much more about your processes/techniques than the individual details. Every single problem will be different and unique and you’ll have to use some combination of all of your skills you’ve built up over your life to solve them.

I told you the command syntax wrong because I told you off the top of my head. That’s kind of my point I’m making here though. That’s not how I actually work with Docker or IT in general. The way I work is by knowing how to find the answer so that it doesn’t matter what command I need to use or someone is asking about because I know how to instantly see all the Docker commands and what they do in less than 1 second on my command line. I have the tools and process I need to work with Docker without having to memorize all these commands and their variations as those change over time and really aren’t that important since they can easily be found/referenced.

It’s actually the same with the Minecraft server commands. It’s not impressive to memorize all the server admin commands as that doesn’t have any practical value. Again, these can all instantly be seen by typing /? in-game (and they’re actually updated based on what permissions you have). I would probably give you the wrong syntax for the Minecraft admin commands too off the top of my head but this would never matter in reality because when I need a command I know how to find it and wouldn’t make flash cards or anything to try to commit these to memory (you’ll automatically memorize the ones you use enough by just pure repetition eventually, just use the reference for the rest of them and commit your brain to storing more important things that aren’t so easily referenced/found).

If I were hiring an admin I would hire the one that can find any command by using the reference rather than someone who memorized 80% of them but had no idea how to find the other 20%. The person using the reference has a process they are following and will generally be able to solve any problem. The person who works by memorizing everything and recalling it would be the one that would end up being the headache even if they are “faster” sometimes due to their memorization. Sure, you could teach that person how to look up the referenced commands but the issue will be that person has not developed that way of thinking about these types of problems and that is very hard to teach. They’re used to recalling things and the truth is in IT that is impossible above a certain level as there is simply too much to recall and you have to use processes / techniques / your foundational knowledge all together.

I guess my advice to anyone new to Docker or hosting Minecraft servers would be to challenge yourself not to try to think in terms of how to do things one at a time and try to memorize those. Learn how to find ALL of the commands whenever you want and try to think about the problems this way. This will free your brain to think about the *really* hard problems instead of trying to remember countless specific commands. It takes practice (a lifetime of practice really) but it’s very empowering and worth it.

Enjoy and have fun!

Hey shampeon,

Thanks, that helps! So the last one of these I saw for Ubuntu specifically it ended up being a weird bug with ufw. They ended up deleting their rules and adding them again and that actually fixed it. That was about a month ago so I definitely would recommend deleting all the ufw rules and adding them back again since that was recent enough that the bug is probably still floating around out there.

In another case someone else actually had firewalld installed (an alternative to ufw) and they didn’t realize that one was on there. If this is a bare metal install you did yourself it’s a lot more likely to be ufw (while VM deployments tend to have firewalld pop up more often at least in my experience).

Ubuntu 22.04.1 is the recommended platform by Microsoft for running the dedicated server (the Bedrock one for Linux at least) and I use it on many of my systems (and the Docker container uses Ubuntu internally as well). It was my desktop OS until yesterday when the NVIDIA drivers crashed and purging them broke the entire X system so I switched to Pop OS (which has been great so far but that’s beside the point which is that you are running a known good configuration at least as far as the OS goes). The version is important too as you’ve ruled out a bunch of other things it could be here too as there are all kinds of issues that can pop up with older versions but you are on current LTS.

Given that you are running a recommended OS this must be some kind of firewall or configuration issue still. I’d be really curious if you are impacted by the same ufw bug as that other person!