When up'ing a new Docker container for MongoDB 5, 6, 7, and inserting a document in an init.sh script, the 3-byte component of the inserted ObjectId is always the same. The 4-byte timestamp matches the current time and the 5-byte per-process value is different for each execution; so those two components of the ObjectId appear okay.

In my case, the last 3 bytes for the random counter is always 2202d8 (2228952 in base 10).

(This behaviour doesn't occur with MongoDB 4.4, 4.2, 4.0)

Notes:

I've tested this with the following Docker images, with the current version it maps to (in parentheses):

• mongo:7 (7.0.9)
• mongo:7.0.8
• mongo:6 (6.0.15)
• mongo:5 (5.0.26)
• mongodb/mongodb-community-server:7.0-ubuntu2204 (7.0.9)
• mongodb/mongodb-community-server:6.0-ubuntu2204 (6.0.15)

Even starting the exact same container twice (after deleting the db folder) should not have the same last 3-bytes for Counter, and surely not when starting containers from different images.

The behaviour does not occur for:

• mongo:4.4
• mongo:4.2
• mongodb/mongodb-community-server:4.4.0-ubuntu2004

When using the mongodb/mongodb-community-server images, rename the env vars to MONGODB_INITDB_ROOT_.... (Also, the first 'up' runs the init and then fails; so start it again without deleting the db volume)
When using any of the 4.x images, change the mongosh to mongo in init.sh.

Impact

• I don't expect that any Devs or DevOps are counting on only the last 3-bytes to always be random. (Or at least, I hope not.) The ObjectId itself is random and that should be the only thing relied upon to not have a collision.
• So there should almost no security implication and no impact on data integrity, etc.
• May be more relevant to know how/why this behaviour occurs
• Whether it's the same 3-bytes for other users or a different 3-bytes may also matter; and of course, if it occurs at all.