A rather popular bug has excited many MongoDB users when they were unable to connect to their database servers. The cause of this failure could be due to recent events at MongoDB Inc. that left users with idle database servers. When trying to connect via the mongosh client, the server gave the standard response of "mongodb://127.0.0.0.1:27017/?directconnection=true&serverselectiontimeoutms=2000&appname=mongosh+2.1.1", when there was a local connection.
To solve the problem, it is necessary to understand the principle of interaction between the client and the database server. In this case, both client and server are on the same machine. Accordingly, calls from the client to the server will go through loopback, however, in your case it may be another server in the network.
The client or mongosh utility generates a request which it passes to the server port to attempt to connect. If successful we will see the MongoDB interface to interact with the server, if unsuccessful we will see an error response. The reasons for this can be quite different. Starting from not running daemon and ending with network unavailability of the server.
All steps in the tutorial can be performed on cloud servers.
The daemon has been deactivated
First, let's check the MongoDB daemon's functionality using the systemd service management system, if your OS uses a different system, check with it:
systemctl status mongod 
As we can see from the screenshot, the service is disabled and not functioning, let's try to start it:
systemctl start mongod Next, let's check the state of the running unit in the system for errors:
journalctl -xeu mongod 
Great, the service has been started, we can see it by the lines "job for unit finished successfully". However, the problem is not always in an unstarted daemon, MongoDB configuration problem is also a common error.
Connection and configuration error
When connecting to the server check the correctness of your request, in the error described earlier there is an entry "mongodb://127.0.0.1:27017/?directconnection=true", which indicates a connection to a local server, if you want to use a remote server, then write the following syntax: mongosh mongodb://myuser:mypassword@123.456.789.0:27017/mydatabase. Of course, you need to replace the username, password, as well as the IP address and port with the name of your database to connect correctly.
If this doesn't work, then be sure to check the network availability of your server on the port on which it should be listening for connections, using a utility. However, if you don't have one, set it with the command:
apt install netcat-traditional -yLet's check the connection:
nc -zv 127.0.0.1 27017
On our server the service is running, so the response is there, but in your case it may be different. If the port is closed, then go to the config:
nano /etc/mongod.conf
Let's make sure that the network settings meet our expectations and the server is listening on the correct port, address. If not, change the data, save the file using Ctrl + O and restart our service!
System user has no rights
MongoDB creates a service and a user and specifies in the unit that it will be run from it. This allows you to limit the software rights to the necessary ones, as well as control access to the database files. To check if the config belongs to our user in the storage folder, let's write the command:
ls -la /etc/mongod.conf 
On the left we see access rights for three groups, where it is specified that the owner can write and read to the file. The others and the owner group can only read. The owner in this case is root, which is also acceptable, the main thing is that the "others" category in which mongodb is located should have read access or be an owner with permissions. To grant permissions we use the chmod command:
chmod 644 /etc/mongod.conf
After that, test the connection again and restart the mongod daemon!
In general, understanding the causes of this error and using appropriate tools to diagnose and resolve the problem will help you successfully restore MongoDB operation and troubleshoot database server connectivity issues.
