Lab - Change the Default DB Path - Error

MongoDB University M103: Basic Cluster Administration
#1

Mongodb is running as requested in the lab but it is running under mongodb user, not some vagrant user which in fact cannot own the process. permissions on /var/mongodb/db folder as set accorgingly for user mongodb in group mongodb: mongodb:mongodb.

however, the validation script fails:

vagrant@m103:/var/m103/validation$ ./validate_lab_change_dbpath
Mongod was not started by the correct user - remember NOT to run mongod as root.

Mongodb is NOT running as root. It is running under it’s own user. Why is the script failing?

#2

try validate_lab_change_dbpath without the ./
also I use vagrant:vagrant not mongodb:mongodb

#3

did that…same issue. I am not able to check exactly what the validation script does, the thing is that it fails in each way I try. with permissions set as vagrant:vagrant the mongod does not even start because of permission issue. I would have to change the permissions to 777 for it to start correctly.

#4

at this point I am thinking the scripts are wrong which would not surprise me since it is not the first time it happens. mongod is running under mongodb user and I suppose the script expects it to run under vagrant user which is not possible.

vagrant@m103:/var$ validate_lab_change_dbpath
Mongod was not started by the correct user - remember NOT to run mongod as root.
vagrant@m103:/var$ ps -aux | grep mongodb
mongodb 6294 1.1 2.4 1103240 51128 ? Sl 20:40 0:02 /usr/bin/mongod --config /etc/mongod.conf
vagrant 6339 0.0 0.0 8868 648 pts/0 S+ 20:44 0:00 grep --color=auto mongodb

vagrant@m103:/var$ mongo --port 27000
MongoDB shell version v3.6.8
connecting to: mongodb://127.0.0.1:27000/
MongoDB server version: 3.6.8
Welcome to the MongoDB shell.
For interactive help, type “help”.
For more comprehensive documentation, see
http://docs.mongodb.org/
Questions? Try the support group
http://groups.google.com/group/mongodb-user
MongoDB Enterprise >

However, mongodb is started (see above) but it is reported as stopped:

vagrant@m103:/etc/init.d$ sudo service mongod status
mongod stop/waiting
vagrant@m103:/etc/init.d$

vagrant@m103:/etc/init.d$ sudo service mongod start
mongod start/running, process 6560
vagrant@m103:/etc/init.d$ sudo service mongod status
mongod stop/waiting
vagrant@m103:/etc/init.d$

At this point I am thinking that the provisioning of the VM is also wrong which would again not surprise me.

1 Like
#5

Sry that you have problem maybe you skipped a step in the installation instructions, if you did you can get some help from @Kanika

#6

Hi AlexToth,

Few mistakes that you can correct:

  • First, you have to make sure you are using config file which you must have created in your previous lab and not /etc/mongod.conf
  • Then, you need to make sure that owner of this directory /var/mongodb/db/ is vagrant. You have to use chown command. If it shows Operation not permitted, use sudo.
  • use chown to change the owner of this directory to vagrant:vagrant

It should work fine. Let me know if you still have issues.

– If I am understanding correct, we want the directory to be owned by vagrant user and not that mongod should be running from vagrant user. You are checking default mongod process.

  • We want you to create your own configuration file.
  • Change the default db path (means in your own directory created by you.)
  • Create a user m103-admin on admin database.
  • Port should be 27000.
  • Authentication should be enabled.
  • bindIp: “192.168.103.100,127.0.0.1”

Kanika

#7

Hello

Thank you for your answer. This is exactly how I have the environment set up. If I leave the owner of the folder to vagrant:vagrant, mongod does not even start. If I leave it to vagrant:vagrant and change the permissions to 777 mongod starts but the script reports the above mentioned error. With mongodb:mongodb as owner of the folder, the mongod starts without altering the permission, but the script returns the same error as above. The validation script in the previous lab worked fine. The one in this lab fails as described.

#8

I have even re provisioned the machine and started from scratch and I have the same error.

#9

You have your own mongod.conf file, right? Not /etc/mongod.conf file.

Please paste the content here.

Kanika

#10

storage:
dbPath: /var/mongodb/db/
journal:
enabled: true

systemLog:
destination: file
logAppend: true
path: /var/mongodb/db/mongod.log

security:
authorization: enabled

net:
port: 27000
bindIp: 127.0.0.1,192.168.103.100

processManagement:
timeZoneInfo: /usr/share/zoneinfo
fork: true

#11

Facing with the same issue. Any progress?

#12

Hi Kanikasingla,

Please visit this thread as well…

even, i’m facing some issue related to changing the default dbpath through the newly created config file.
Please see my reply to “hakan_27844”.

thanks in advance for your help.

#13

I don’t think I get it. I created a copy of /etc/mongod.conf, modified it accordingly and that is what I use in my VM. mongod is started like a normal daemon: service mongod start.

why is the user so important and why is it checked since in the first lesson it was mention that it is only recommended to use Vagrant, not mandatory. so technically I can have my own setup on my own vm and I should be able to run the validation scripts. The scripts should parse the configuration file and get values from mongodb via the created user not check the service user. For me this is completely irrelevant.

#14

Hi Pawan,

Please check my reply here

Kanika

#15

Hi AlexToth,

Unfortunately vagrant is not optional for this course. You can still run the course locally but won’t be able to submit homework.

There is a lab too with proper instructions on how to setup your vagrant. Also, if you face issues, I have tried to mention some steps and troubleshooting here.

Let me know if I can help you more!

Kanika

#16

I attempted to start mongod using sudo. This caused the validation step to fail showing I should not start as root. I then restarted mongod without sudo and received the error stated above.

My original start using sudo polluted my directory /var/mongod/db with files owned by root. I had to clear out this directory before I could restart without sudo as user “vagrant”.

the logfile error message: “exception in initAndListen: IllegalOperation: Attempted to create a lock file on a read-only directory: /var/mongodb/db, terminating” is a little misleading. In my case, the directory was not read-only. The lock file was in contention with the process. The lock file already existed but was owned by root. Clearing this out allowed the files to be created as expected.

1 Like
#17

Or to summarize: “understand what you’re doing with these Linux commands”. Only use “sudo” when you need to do stuff as “root”, which in M103 happens very rarely.

And unfortunately you are correct: students will probably need to know Linux-101 to troubleshoot and fix any mistakes they may make along the way. That’s often a challenge with courses like these: students are being introduced to new, technical concepts that run on platforms they also have little experience with. Thus, getting up and running is always going to be a bit rough the first day.

#18

Hi @Barron_43628,

Nice you got it working!

If I will get this error, I will check the permissions on my working directory that is /var/mongodb/db.

And as @Tess_Sluijter mentioned, sudo is not something that someone should use frequently. If in the course, we expect students to use sudo, we will explicitly mention it on the Lab/Quiz but if it is not mentioned, then you don’t need to use sudo.

Hope it clears the confusion!

Kanika

#19

Hi @Kanika,

in addition to verifying the directory permissions, look to see no files with unexpected ownership are in conflict with the process. The error message suggests the directory is in conflict, but in my example the directory was fine and not a read-only directory. Instead a file was in conflict. This file resided inside the directory the error message referred to. But still I get an error about a directory. (Again, the directory is not the conflict).

#20

Hi Barron_43628,

Thanks for the catch! Will see what we can do about this.

Keep Learning, Kanika