“Missing or unsupported mandatory dependencies” on a Forge or NeoForge server: what the block means and how to fix it

Last updated 2026-09-14 · MineXHost

Forge and NeoForge check that every mod's required dependencies are present before Minecraft starts. This message means at least one is missing, or is there in a version the requiring mod will not accept. The output names both the mod that is asking and the mod it is asking for, and the fix is nearly always one download into the mods folder.

What the error means

Every Forge and NeoForge mod declares its hard dependencies in its own metadata, with a version range for each. Before any game code runs, the loader checks every declared dependency against the jars actually in mods/. If one is absent, or present but outside the range, the loader stops there and prints what it wanted.

Minecraft has not started at this point. No world was loaded, nothing is corrupted, and the fix lives entirely in the mods folder.

The wordings you will see

The same failure is printed in several shapes depending on the loader version and on whether you are reading the console or the crash report. Search for the one in your log, not a paraphrase of it.

The four cases behind it

1. A library that is simply missing

The commonest case by far. Many mods depend on a shared library mod — a rendering library, a config library, a data library — that is a separate download rather than something bundled in the mod's own jar. A pack installed by hand, or a mod added on top of a pack, often arrives without it.

2. A dependency that is present but too old

One mod was updated and the library it depends on was not. The requiring mod declares a version floor, the installed copy sits below it, and the loader refuses. The fix is to update the library, not to remove the mod — but only to a version every other mod in the pack also accepts, which is why a pack that pins its library versions can be hard to update one jar at a time.

3. A dependency that is present and still rejected

The requires line has no version floor and the Currently line shows a version anyway. The dependency is installed; the mod will not take it. In practice this is a Fabric mod running on a Forge server through a compatibility layer, asking for the Fabric build of a library and being handed the Forge one. There is nothing to download here and nothing to bump — the pair does not fit, and the answer is to drop the mod or find a native build of it for your loader.

4. The server is on the wrong Minecraft or loader version

If the thing being required is minecraft or forge or neoforge itself — Mod y requires forge 47.3.0 or above, Currently forge is 47.2.0 — no mod download fixes it. The pack wants a newer loader build, or a different Minecraft version, than the server is running.

Working through it

1. Read the Currently line for each dependency named. Sort them into missing, too old, rejected, and loader-version.
2. For a loader-version line, fix that first: re-install the server on the Forge or NeoForge build and Minecraft version the pack targets. Everything else may resolve with it.
3. For a missing dependency, download the library for your exact Minecraft version and loader — Forge and NeoForge builds of the same library are different jars — and drop it into mods/.
4. For a too-old dependency, replace the old jar with a newer one that satisfies the floor. Remove the old jar; do not keep both.
5. For a rejected dependency, remove the requiring mod, or replace it with a build made for your loader. Nothing else resolves it.
6. Restart after each change so you can tell which change fixed what. A pack with three missing libraries surfaces them one boot at a time.

What MineXHost's launcher does with this crash

Every server here is started by MineXEngine, our own launcher. Before the first boot it computes every hard dependency your kept mods declare and checks that something in mods/ provides it. A provable miss is restored from the quarantine folder if the engine itself moved it aside, or fetched — a handful per boot, each verified to declare the mod id that was asked for before it is placed.

When the loader still reports a missing dependency at boot, the engine reads the ids and version ranges out of the block, prints “Server stopped: missing dependency '<id>'. Fetching it and restarting” in your console, downloads a build for your Minecraft version and loader, and restarts. It tries this up to three times and then stops rather than looping.

For a present-but-too-old dependency, the engine bumps the library only when that is provably safe: the newer build must be the same major version, and every other installed mod's declared range must accept it. A jump across a major version, or a range that excludes the floor, is reported as a pack problem with the mod and the version named — because bumping it would break something else.

For a present-and-rejected dependency, there is nothing to fetch and nothing to bump, so the engine says so and names the pair. On your server it never removes the requiring mod for you: crash recovery is identify-only on customer servers, so the mod is named in the console and your mods folder stays as you uploaded it. Automatic fetching of a missing library is the one thing it does add — a download into mods/, never a removal from it.