Reputation: 3781
Earlier i was storing all the mongodb data files in /var/lib/mongodb directory..and the dbpath entry in /etc/mongodb.conf was /var/lib/mongodb..
Now i want to change the data directory to /vol/db..so I created the directory /vol/db and changed the permissions using sudo chown -R id -u
/vol/db and changed the db path entry to /vol/db in /etc/mongodb.conf
now when i start the mongodb using sudo service mongodb start..i am getting this error in /var/log/mongodb/mongodb.log
i need help..where I am wrong?
Upvotes: 42
Views: 63799
Reputation: 94
Depending on the linux distro you are using the command could be different to change the permission of the directory. I'm using centOS and Mongodb version I using is 8. It worked when I did this.
sudo chown -R mongod:mongod /var/lib/mongo
sudo systemctl restart mongod
Just make sure you check the /var/lib
directory to see what mongo director/folder you are change; Sometimes it's mongodb
and sometimes its mongo
Upvotes: 0
Reputation: 1316
I was having the same problem, but was able to solve it thanks to a similar question. You need to make sure that /vol/db/
is owned by mongodb
.
sudo chown -R mongodb:mongodb /vol/db/
If you get the error chown: invalid user: 'mongodb:mongodb'
, check /etc/passwd
to see if there is a similar user that exists (ex. mongod
).
Upvotes: 56
Reputation: 4106
Try the following:
$ sudo chmod 755 /vol/db && sudo chown $USER /vol/db
Upvotes: 2
Reputation: 67
I suggest to check what is the error by reading mongo log
tail -50 /var/log/mongodb/mongodb.log
you can immediately find the problem(including permission ones)
Upvotes: 2
Reputation: 7952
If after changing permissions and ownership of the new db path, you're still seeing this issue, run getenforce
to see if you are using a system with SELinux running in enforce mode.
If getenforce returns 'enforcing', it's likely selinux is the cause of the permissions error, since mongodb is now running outside it's original context scope since the db location changed out of /var/lib/...
I don't know the details, but a brute force way then to resolve the issue without writing your own selinux policy for the new context is to simply turn off selinux :-/
sudo setenforce 0
Ideally, you'd figure out how to update the selinux policy if you're planning to run in production.
Upvotes: 7