Guidefor everyones4 min read
Fixing "Missing required datapack registries" in Minecraft
The error names the exact registries that don't match, and the namespace in front of each one names the mod. What a datapack registry is, why this is not a version mismatch, and how to fix it.
What the error is telling you
Missing required datapack registries: moonlight:soft_fluids, moonlight:map_markers
The client tried to join, and the server told it that two registries it requires aren't present, or don't match, on the client's side. The names before the colons are the namespaces of the mods that own those registries. That's not decoration, it's the most useful part of the message: it tells you exactly which mod is responsible, without you having to guess from a mod list.
In this example, moonlight is the mod id for Moonlight Lib, a shared library mod used
by several content mods. The server has it. The client either doesn't, has a different
version of it, or has a newer version than the server does. Any of those three produces this
exact error.
This is not the outdated client/server error
It's worth ruling this out first, because the two errors look like siblings and are not.
Outdated client and outdated server is a protocol mismatch. The client and server are built for different Minecraft versions, and the game refuses the connection before anything else happens.
This error is a content mismatch. It can happen between two installations on the identical Minecraft version, running the identical mod loader, where every other mod matches perfectly. The only thing wrong is that one mod's datapack registries don't agree between the two sides. Same failure category as bad packet id errors in the sense that something didn't match during connection, but a completely different layer: this one has nothing to do with the network protocol at all.
What a datapack registry actually is
Since Minecraft 1.19, mods and vanilla itself can define custom datapack registries: collections of data-driven content loaded the same way vanilla loads loot tables, recipes, and worldgen features, as JSON files rather than compiled code. A mod that adds configurable fluids, custom map markers, or data-driven structures typically does it by registering one of these.
The part that causes this error is a stricter check Minecraft added alongside that system. Before a client is allowed to join, the game verifies that the full contents of every registry match between client and server, not just that both sides have the mod installed. This is a tighter check than older Minecraft versions ran, and it exists specifically to prevent silent desync: without it, a client and server disagreeing quietly about what a registry contains used to produce subtle, hard-to-diagnose bugs instead of a clean refusal to connect. The trade-off is a connection that fails loudly and immediately if anything is off, which is what you're looking at.
Why this specific error happens
The server has a mod that registers custom datapack registries. The client is missing that mod, has an incompatible version of it, or has a newer version the server doesn't recognize. Because the check requires an exact match, there's no partial credit: a library that's otherwise invisible to players, doing no more than providing shared code other mods build on, can block every connection to the server the moment its version drifts on one side.
That's exactly the shape of the real reports this error comes from. Four separate users
reported this exact message, Missing required datapack registries: moonlight:soft_fluids, moonlight:map_markers, in Moonlight Lib's own comment section, each hitting it while trying
to join a server that used content mods depending on it. Moonlight Lib itself does nothing
visibly dramatic. It's a shared library other mods lean on, which is precisely why a mismatch
in it is easy to overlook while checking the mods players can actually see.
The fix
- Read the namespace in your own error message. Everything before each colon is a mod id. Look that id up (its Modrinth or CurseForge page, or the mod list on the server) to identify the exact mod.
- Check that mod's version on both sides. Not just that it's installed on both, the version string itself, on the client and in the server's mods folder.
- Match them exactly. Update whichever side is behind, or roll back whichever side is ahead, until both report the same version.
- Restart both sides after changing anything. A server that was already running with the old jar in memory won't pick up a swapped file until it restarts.
This is very often the same root cause as a mod's core and addon jars falling out of sync: many mods, Moonlight Lib included, ship as a base library plus one or more addon jars, and it's easy to update one half of that pair without the other. If you're chasing this down, check every jar tied to the mod named in the error, not just the one whose name matches it exactly, since an outdated addon jar can carry an outdated copy of the registry data even when the core library itself is current on both sides.
This is a general mechanic, not a Moonlight Lib problem
Moonlight Lib is the mod behind the real reports this guide is based on, but the mechanism
belongs to Minecraft and the mod loaders, not to any one mod. Any mod that registers a custom
datapack registry, library or otherwise, can produce this exact error shape with its own
namespace in place of moonlight. If your error names a different mod, the read is the same:
that mod's version disagrees between your client and the server, and matching the two
versions is the fix.
Checking before you connect
Two facts settle this every time:
- Which mod owns each namespace named in the error.
- Whether that mod's version matches, exactly, between the client and the server.
If both versions match and the error still appears, confirm the mod isn't shipping mismatched core and addon jars on one side. Once every namespace in the message resolves to a mod that's identical on both ends, the connection goes through.
