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
If you have locked yourself out then you need to do the following:
- Stop your MongoDB instance
- Remove the --auth and/or --keyfile options from your MongoDB config to disable authentication
- Start the instance without authentication
- Edit the users as needed
- Restart the instance with authentication enabled
-
-
keyFile
impliessecurity.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:
- Open the MongoDB configuration file using
sudo
(sudo vi mongodb.conf
).
The file can be found in/etc/
folder. - Comment
"auth = true"
. - Stop the MongoDB service (
sudo service mongod stop
) - Start the MongoDB service (
sudo service mongod start
) Then create "root" superuser using the below command:
use admin db.createUser({user:"admin",pwd:"password",roles:[{role:"root",db:"admin"}]});
For reference https://docs.mongodb.com/manual/reference/built-in-roles/#superuser-roles
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! :)– WoppiFeb 8, 2018 at 7:39
-
-
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– vikramviDec 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.
security:
keyFile: <path-to-keyfile>
replication:
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
-
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.– stack3rMar 31, 2023 at 22:51
Check the answers to this question, they might help
https://stackoverflow.com/questions/20117104/mongodb-root-user
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/
-
1As mentioned in the post, that's the only info I've been able to find. I don't have permissions to do that– TonyApr 11, 2014 at 3:40
@Divya's answer helped but was not complete for me. Here's what I had to do:
Steps
- Connect to the machine that was hosting my MongoDB instance
- Open the MongoDB configuration file found in
/etc/
folder using:sudo nano mongod.conf
- Comment out the following code like so:
# security: # authorization: enabled
- Stop the MongoDB service:
sudo service mongod stop
- Start the MongoDB service:
sudo service mongod start
- 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"}] });
- Go back and uncomment the lines from step 3. Then repeat steps 4 and 5.
- You should now be able to authenticate with the new user you created in step 6 and have full access to the database.
Troubleshooting
- 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 asmongod.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
-
2This 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.– davehApr 16, 2014 at 1:35
-