I am witnessing a very bizzare behaviour of MongoDB.

I launch MongoD on a test system (Windows 10, 64bit) like this:

"C:\Program Files\MongoDB\Server\3.6\bin\mongod.exe" --dbpath "C:\MongoData"

I then shut down the server and replace the MongoData directory with a data set from a production server. I start mongod again, but I get a collection with 4 documents, which is what I used to have before I replaced my test data set with a real one.

That's not right, because I would expect to see loads of documents in a real data set. I then try dozens of things, including pointing MongoD to the data folder in its original location, which gives me all the documents from the real collection. Phew, the data is safe. But what is happening in my test system?

I have noticed that if I rename the folder in my test system to MongoData2 and lanuch mongod pointing at it then I get my proper production data set. but if I rename it back to MongoData and launch mongod pointing at this folder I get 4 documents again.

What is causing this?

  • 1
    Are you copying/renaming a dbPath with a complete copy of all data files? MongoDB data files don't have the directory path encoded within them, so back up by copying underlying data files should work as long as you are copying all files (and have shutdown any associated MongoDB servers before copying or replacing dbPath contents). If you aren't seeing expected data I would check your MongoDB server log for any startup errors (eg. file permissions or missing files) and ensure the expected dbPath is used.
    – Stennie
    Feb 25, 2019 at 22:41
  • @Stennie I have stopped the server in Prod, and made an archive of the entire folder in dbPath. Now I restore it upon request and keep getting different results whenever I start the server in a different way...
    – Tony Sepia
    Feb 26, 2019 at 0:19

2 Answers 2


As per MongoDB documentation here To use an alternate dbpath, specify the path in the configuration file (e.g. C:\mongodb\mongod.cfg) or on the command line with the --dbpath option.

Default: /data/db on Linux and macOS, \data\db on Windows

The directory where the mongod instance stores its data.

Changed in version 3.0: The files in --dbpath must correspond to the storage engine specified in --storageEngine. If the data files do not correspond to --storageEngine, mongod will refuse to start.


Uses a separate directory to store data for each database. The directories are under the --dbpath directory, and each subdirectory name corresponds to the database name.

Changed in version 3.0: To change the --directoryperdb option for existing deployments, you must restart the mongod instances with the new --directoryperdb value and a new data directory (--dbpath ), and then repopulate the data.

  • For standalone instances, you can use mongodump on the existing instance, stop the instance, restart with the new --directoryperdb value and a new data directory, and use mongorestore to populate the new data directory.
  • For replica sets, you can update in a rolling manner by stopping a secondary member, restart with the new --directoryperdb value and a new data directory, and use initial sync to populate the new data directory. To update all members, start with the secondary members first. Then step down the primary, and update the stepped-down member.
  • With all this in mind, can you please specify why changing the DIRECTORY NAME in BOTH the file system and the configuration would result in different data sets being produced? I.e. I rename folder to folder1, start mongod with --dbpath /folder1 I get data set 1, then rename the same folder to folder2, start mongod with --dbpath /folder2 I get a different data set
    – Tony Sepia
    Feb 25, 2019 at 10:35
  • @TonySepia, Could you please update the log files , after successfully execution of mongod . Feb 25, 2019 at 10:49
  • Do you mean upload the log files?
    – Tony Sepia
    Feb 25, 2019 at 10:51
  • @TonySepia,No, I mean to say that after changing the --dbpath name of the Test Data. When you are running the mongod. Did you get any warning message or else. Feb 25, 2019 at 10:59
  • No, not a single warning!
    – Tony Sepia
    Feb 25, 2019 at 13:10

Looks like the local COMODO firewall was partially blocking the application with its HIPS feature. I have used command-line arguments to control the DB path, so I'm not totally surprised that it may have affected what MongoD was seeing.

The latest symptom was the database 'forgetting' the newly created users. After allowing the app through the firewall all works well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.