Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a MongoDB 2.0.4 installation on Ubuntu 12.10. Recently I had some problems connecting to the database from the outside, and figured out there was something which prevented MongoDB from starting correctly. As suggested on several sources (see StackOverflow) I removed /var/lib/mongodb/mongodb.lock and ran mongod --repair. This didn't solve the problem, MongoDB wouldn't run and kept creating lock files that it didn't take care of removing afterwards. By looking at the logs, I realized that it didn't have access to some folder called $tmpSomething, so (since the name suggested a temporary folder) I removed it, and afterwards it all worked ... except the fact that I only have one of my previous databases in sight, while the other ones are still there because my /var/lib/mongodb/ folder is still full of .ns .0 .1 .n files that weight a lot. Is there a way to restore them into the database? (I have tried with mongorestore, but as I was expecting, it doesn't handle those files).


share|improve this question
up vote 8 down vote accepted

The .ns .0 .1 etc. files are the data files themselves. If you started a mongod instance with a --dbpath argument pointing at that folder, or if you moved the contents somewhere else and used the option to point there, mongod will attempt to read them as normal.

Since your issues suggest corruption and/or some other issue starting mongod (you should really post the startup messages log files, perhaps in a separate question to address that issue), then there are alternatives. For reference, the most common problems are permissions related, especially when people try to start mongod manually (as themselves) or with sudo (as root) and create problematic permissions in the various directories.

You are correct that mongorestore cannot use these data files directly, but mongodump can read them and dump data from them into the BSON files that mongorestore expects.

The option you want here is dbpath. You mention your path is /var/lib/mongo, so you can run something like this:

mongodump --dbpath /var/lib/mongo -d <database name> -o /path/to/put/files

Optionally you can use --repair here too to fix corruption along with the query options in extreme circumstances to get around corrupted sections (rarely, if ever, needed). The various options are described on the mongodump page:

Once you dump the files out, you can use mongorestore to reimport them into another mongod instance.

share|improve this answer
Mongodump 3.0+ no longer has the --dbpath flag. – doub1ejack Sep 18 '15 at 15:05
correct, you will notice that the question was asked about version 2.0.4 - mongodump will only support repair for the MMAP engine now too - with later versions and in particular with WiredTiger you are limited to the repair option with mongod, mongodump is no longer an option – Adam C Sep 18 '15 at 15:55
With Mongo 3.0 an option is to start the mongo server with specified files: mongod --dbpath ./ and then proceed with the mongodump without the --dbpath – Shwaydogg Jan 3 at 0:33
Just a note, if you are running Mongo 3.0 and mongod --dbpath ./ does not give you the database in the .ns .0 files, it could be that the storage engine is defaulting to the new WiredTiger engine instead of the old MMapV1 engine. Try mongod --storageEngine mmapv1 --dbpath ./ instead to connect using the old engine. – flamebaud May 13 at 14:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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