Introduction

This error usually means the MongoDB binary version running in the pod does not agree with the featureCompatibilityVersion, or FCV, stored in admin.system.version. In an operator-managed Kubernetes deployment, that mismatch often shows up after a failed upgrade, a restore from older data, or a version jump that skipped the expected FCV transition sequence.

What FCV Actually Controls

MongoDB stores the FCV document in the admin.system.version collection. The FCV tells the server which feature set it should operate with while maintaining compatibility across a replica set or sharded cluster during upgrades and downgrades.

That means two version concepts matter:

• The MongoDB binary version running in the container
• The FCV recorded in the database metadata

If those drift too far apart, MongoDB may refuse to start cleanly or the operator may fail reconciliation with an error about an invalid FCV document.

Check the Running Version and FCV

In Kubernetes, start by inspecting one of the MongoDB pods:

kubectl exec -it -n data mongo-0 -- \
  mongosh admin --eval 'db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })'

You also want to know which binary version the pod is actually running:

kubectl exec -it -n data mongo-0 -- mongod --version

If the binary says one major version and the FCV document implies another incompatible state, you have found the root of the problem.

Fix the Mismatch the Supported Way

The safe fix is to bring the cluster into a supported version/FCV combination and then set the FCV through MongoDB commands, not by editing admin.system.version directly.

Example:

db.adminCommand({ setFeatureCompatibilityVersion: "6.0" })

Run that only after:

1. The replica set is healthy
2. All relevant members are on the expected MongoDB binary version
3. You are following a supported upgrade or downgrade path

In operator-managed environments, that often means letting the operator finish the image rollout first, then applying the FCV change if your upgrade process requires it.

Why This Happens in Kubernetes Operators

Operators automate version changes, but they still depend on MongoDB's own upgrade rules. Common triggers include:

• Restoring data files or volumes from an older cluster into newer pods
• Changing the MongoDB image tag without following the normal upgrade path
• A partially completed upgrade where some members moved forward and others did not
• Manual intervention in system collections that left the FCV document malformed or stale

The operator is not inventing the problem. It is surfacing a mismatch that already exists in the underlying MongoDB state.

Do Not Edit admin.system.version By Hand

The temptation is often to patch the FCV document manually because the error message mentions that collection directly. Avoid that. The supported mechanism is setFeatureCompatibilityVersion, because it performs validation and related server-side bookkeeping.

Manual writes to internal metadata collections can make the cluster harder to recover, especially when the operator keeps reconciling against a broken state.

Common Pitfalls

• Skipping directly between unsupported MongoDB major versions often creates FCV problems during startup or reconciliation.
• Restoring a PVC or snapshot into a pod with a newer image can bring old FCV metadata along for the ride.
• Trying to fix the issue by editing admin.system.version manually is risky and unsupported.
• Checking only the operator logs without verifying the actual mongod binary version and current FCV leaves the root cause half-diagnosed.

Summary

• The error means MongoDB's stored FCV does not match the server state the operator is trying to run.
• Check both the running binary version and the FCV value from mongosh.
• Use setFeatureCompatibilityVersion only after the cluster is on a supported version path.
• Never treat admin.system.version as an ordinary collection to patch by hand.