Application cannot connect to MongoDB on VM (Centos7 on VMWare)

[jacques lapierre]

Hi everyone,

I've just started learning MongoDB 2 days ago and I installed it on a CentOS 7 VM.

I've written a very basic application to try and connect to it but I always time out.
It works perfectly fine with my local installation of MongoDB but I cannot connect to the one on the VM.

I wrote everything in great detail in this post, I hope someone can help me out

https://stackoverflow.com/questions/57441755/connecting-to-mongodb-running-on-vm

[Tim Holloway]

Welcome to the Ranch, Jacques!

There are basically 3 things to check.

1. Is the MongoDB server actually up and running on the VM (if you've installed it as an RPM, probably 'systemctl status mongodb' or something like that will tell you).
2. Is the MongoDB remote connection port published (default is 27017)? "netstat -lnp" (as root) and look for 27017 in the results.
3. Does the VM firewall permit access to the MongoDB remote connection port? (iptables or whatever firewall manager you're using)

If these 3 things are true then as long as the client is attempting to connect to the right server and port things will work. Generally you can test this using a stand-alone web utility like curl or wget.

[jacques lapierre]

hi tim, thanks for your reply!

i was under the impression the server was running for sure since i ran the mongod command and the mongo command afterwards where i was able to create collections and add documents in the shell.
but apparently that's not the same as running the service since systemctl status mongod gives me the following output:

● mongod.service - MongoDB Database Server
  Loaded: loaded (/usr/lib/systemd/system/mongod.service; enabled; vendor preset: disabled)
  Active: failed (Result: exit-code) since Thu 2019-08-15 17:53:42 CEST; 1min 29s ago
    Docs: https://docs.mongodb.org/manual
 Process: 2826 ExecStart=/usr/bin/mongod $OPTIONS (code=exited, status=2)

Aug 15 17:53:42 BusinessVM systemd[1]: Starting MongoDB Database Server...
Aug 15 17:53:42 BusinessVM systemd[1]: mongod.service: control process exited, code=exited status=2
Aug 15 17:53:42 BusinessVM systemd[1]: Failed to start MongoDB Database Server.
Aug 15 17:53:42 BusinessVM systemd[1]: Unit mongod.service entered failed state.
Aug 15 17:53:42 BusinessVM systemd[1]: mongod.service failed.

when i googled these messages i found the 2 most common reasons are either a faulty /etc/mongod.conf file or the user not having ownership / access rights over the dbpath folders.
i could not find any issue with the mongod file, and the dbpath folders (/data/db) belong to root. but since i attempt to start the service as root this should not be an issue.

my /etc/mongod.conf file looks as follows:

# mongod.conf

# for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/

# where to write logging data.
systemLog:
 destination: file
 logAppend: true
 path: /var/log/mongodb/mongod.log

# Where and how to store data.
storage:
 dbPath: /data/db
 journal:
   enabled: true
#  engine:
#  mmapv1:
#  wiredTiger:

# how the process runs
processManagement:
 fork: true  # fork and run in background
 pidFilePath: /var/run/mongodb/mongod.pid  # location of pidfile
 timeZoneInfo: /usr/share/zoneinfo

# network interfaces
net:
 port: 27017
#  bindIp: 127.0.0.1  # Enter 0.0.0.0,:: to bind to all IPv4 and IPv6 addresses or, alternatively, use the net.bindIpAll setting.
  bindIp: 0.0.0.0,::

#security:

#operationProfiling:

#replication:

#sharding:

## Enterprise-Only Options

#auditLog:

#snmp:


do you have any more ideas what i might try?

[Tim Holloway]

Look at /var/log/mongodb for messages. Also "journalctl -xe".

Plus, make sure that the directory /data/db directory exists and that the mongodb userid can read and write to it.

[jacques lapierre]

The issue seems to be the changes that I've made to the /etc/mongod.conf file.
When i revert everything back to how it was originally, i can start the service with systemctl start mongod.service.

However when I attempt to change the dbPath in the config file, it won't start anymore. I did create the /data/db folder and changed the user- and group ownership to that of the original path, which were called "mongod".
No matter what I tried though I couldn't get it to work.

It would also no longer start when I changed the bindIp to 0.0.0.0,:: (because it states "Enter 0.0.0.0,:: to bind to all IPv4 and IPv6 addresses").
I attempted to do this so I could connect to the DB on the virtual machine from my host PC. But since it wouldn't start after this change anymore I resorted to just commenting out the entire line.

So with the default dbPath and the commented out bindIp line I started the service, that much worked and the service was active.
I still timed out so I took a look at the next thing on the list.

Ran netstat -lnp | grep 27017 as root and got:
tcp        0      0 127.0.0.1:27017         0.0.0.0:*               LISTEN      50648/mongod        
unix  2      [ ACC ]     STREAM     LISTENING     2857512  50648/mongod         /tmp/mongodb-27017.sock

This far it seems fine to me, the port is also set to 27017 in the config file.


As for the firewall, I'm not really that experienced with VMWare or Linux yet to know how to evaluate this but I'll look around. I didn't change anything really after the CentOS 7 installation. Got the KDE applications but not much more. MongoDB was the only thing I installed after the OS installation.
And still would really like to know what I'm missing that I cannot change the dbPath or bindIp value in the config file.

[Tim Holloway]

One other thing that might block access to /data/db is selinux. You can temporarily disable selinux with the "set enforce off" console command. If that helps, then you will need to modify the selinux attributes on that directory.

A better option for bindIP would be:

bindIp: *

for all IPV4 and IPV6 addresses, or

bindIp: 0.0.0.0

For all IPV4 and no IPV6 addresses. Note that since the only delimiting in the manual page is in type styles, it's hard to tell English punctuation (end-of-sentence) from network address notation.

Anyway, "It doesn't start" doesn't tell us enough. Always look in the log files and report any errors you see.

Linux firewalls are in transition. The old standard is iptables, but there are some new tools being used now. The iptables command is sufficient for CentOS 7, though, I think:

iptables -I p tcp -s x.x.x.x/y --dport 27017 -j ACCEPT

is a good start. x.x.x.x/y is your local subnet address and mask. For example, 192.168.0.0/16. That will keep outside intruders at bay.

For a VMWare server running under a host OS, the server's firewall would be the firewall of the host OS. Not sure what VMWare does for bare-metal hosting.