I'm was playing around with permissions and locked myself out of Mongo database. I'm pretty sure I did this by trying to explicitly add access to a database but instead I overwrote only allowing permission to the database. So I'm effectively locked out of my Mongo database and everything I read tells me how to create a super user if I have the add user privilege. Right now I don't think I have any users that have that privilege. Is there a way to enter the database as all access? I own the server and have root access.


6 Answers 6


If you have locked yourself out then you need to do the following:

  1. Stop your MongoDB instance
  2. Remove the --auth and/or --keyfile options from your MongoDB config to disable authentication
  3. Start the instance without authentication
  4. Edit the users as needed
  5. Restart the instance with authentication enabled
  • Removing auth was not enough indeed, thanks!
    – Andy
    Oct 18, 2017 at 16:03
  • keyFile implies security.authorization, thus you must remove both. Feb 11 at 10:01

I had a similar issue when I created a user without adding a superuser first. The following steps helped solve the problem:

  1. Open the MongoDB configuration file using sudo (sudo vi mongodb.conf).
    The file can be found in /etc/ folder.
  2. Comment "auth = true".
  3. Stop the MongoDB service (sudo service mongod stop)
  4. Start the MongoDB service (sudo service mongod start)
  5. Then create "root" superuser using the below command:

    use admin

    For reference https://docs.mongodb.com/manual/reference/built-in-roles/#superuser-roles

  6. Go back and uncomment "auth=true". Stop and Start/Restart the mongodb service.

  • I can't thank you enough. I've been stuck trying to figure this out when I uploaded the project to the dev server. Thank you so much! :)
    – Woppi
    Feb 8, 2018 at 7:39
  • Ditto. Server error messages spectacularly unhelpful on this. Thank you!
    – Tom
    Mar 29, 2018 at 7:09
  • I'm using AWS EC2 linux instance and under /etc/ there is mongod.conf and not mongodb.conf. Also I didn't find auth = true entry in the conf file. please clarify
    – vikramvi
    Dec 9, 2019 at 10:52

If you use a replica set with a keyfile

Security between members of the replica set using Internal Authentication

Keyfile is used for auth in replication.

  keyFile: <path-to-keyfile>
  replSetName: <replicaSetName>

You can use this command to login as a admin to mongod:

mongo -u __system -p "$(tr -d '\011-\015\040' < path-to-keyfile)" --authenticationDatabase local

Afterword you are able to create or modify your admin user.

Internal Role

__system MongoDB assigns this role to user objects that represent cluster members, such as replica set members and mongos instances. The role entitles its holder to take any action against any object in the database.

Do not assign this role to user objects representing applications or human administrators, other than in exceptional circumstances.

  • 1
    Where did you find this information? Mar 24, 2019 at 10:53
  • 2
    @octohedron The last file in this diff shows it: github.com/mongodb/mongo/commit/… Another source is percona.com/blog/2019/07/12/mongodb-security-vs-five-bad-guys Oct 9, 2020 at 20:35
  • your method with keyfile worked for me on MongoDB hosted in Kubernetes Engine from GCP, as I did not want to restart mongodb like in the OP's accepted answer. For some reason I was unable to exec directly into the pod using kubectl, but I was able to first "gcloud ssh" into the node, and then using root and "docker ps" available on the host, I found the internal container name, and was able to exec into the container from there instead. GCP seems to have already created a keyfile in my case, and I could see it from 'ps aux', so I reused it.
    – stack3r
    Mar 31, 2023 at 22:51

Check the answers to this question, they might help


Basically if you still have access to the server, you may be able to access the Admin database.

There's more in this page http://docs.mongodb.org/v2.4/reference/user-privileges/

Note that 2.6 version changes how this works completely. For 2.6 you'll need to spend more time with http://docs.mongodb.org/manual/security/

  • 1
    As mentioned in the post, that's the only info I've been able to find. I don't have permissions to do that
    – Tony
    Apr 11, 2014 at 3:40

@Divya's answer helped but was not complete for me. Here's what I had to do:


  1. Connect to the machine that was hosting my MongoDB instance
  2. Open the MongoDB configuration file found in /etc/ folder using: sudo nano mongod.conf
  3. Comment out the following code like so:
    # security:
    #   authorization: enabled
  4. Stop the MongoDB service: sudo service mongod stop
  5. Start the MongoDB service: sudo service mongod start
  6. Connect to the database using Robo3T or equivalent. With a connection to the admin collection, create a new admin superuser:
    db.createUser({ user:"admin", pwd:"password", roles:[{role:"root", db:"admin"}] });
  7. Go back and uncomment the lines from step 3. Then repeat steps 4 and 5.
  8. You should now be able to authenticate with the new user you created in step 6 and have full access to the database.


  • If for whatever reason, after trying to restart your mongo service, you cannot connect to it, you can make sure the service properly started with: systemctl --type=service --state=active. If it has started, it will be in the list as mongod.service.
  • Mongo logs can also be found at /var/log/mongodb/mongodb.log but this is less likely to be helpful in this situation.

You have to stop Mongo, remove the admin files, then start Mongo

sudo service mongod stop
mv /data/admin.* .
sudo service mongod start
  • 2
    This is destroying the administrative users database and allowing access via the "localHostExcetption" it is not a good way to administer users when you have a problem.
    – daveh
    Apr 16, 2014 at 1:35
  • This will destroy your database! Jun 10, 2022 at 21:13

Your Answer

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

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