If you’ve ever worked with JetBackup 5, you’ve probably seen at least one error that makes your heart sink. For me, one of the trickiest was this MongoDB connection issue:

Fatal error: Uncaught MongoDB\Driver\Exception\ConnectionTimeoutException: 
No suitable servers found (serverSelectionTryOnce` set): 
[connection refused calling hello on ‘localhost:27217’]

Looks ugly, right? But here’s the truth: it’s basically JetBackup saying, “Hey, I tried to talk to MongoDB on port 27217, but it wouldn’t answer.” I’ve run into this a few times, and the good news is — there are clear steps you can take to sort it out. Let me walk you through how I usually troubleshoot it.

Start with the Obvious: Are the Services Running?

Most of the time, this error pops up because JetBackup or MongoDB just isn’t running. Check them with:

service jetmongod status

service jetbackup5d status

One quick warning: if a backup or reindex job is running, restarting services will stop them. So, if the job is important, wait until it finishes. If everything starts fine, reload the JetBackup GUI. Sometimes, that’s all it takes.

Disk Space Can Be the Culprit

MongoDB is picky about storage. If your server’s out of space, it won’t run. Run this command:

df -h

If you see a partition at 100%, clean up some files. Logs and temp files usually eat a lot of space. Once you’ve freed up some room, restart:

service jetmongod restart   # give it ~10 seconds

service jetbackup5d restart

Socket File & Permissions

MongoDB relies on a socket file — you’ll find it at /tmp/mongodb-27217.sock. It needs to belong to mongod:mongod.

Also check the /tmp folder itself:

ls -ld /tmp

It should show drwxrwxrwt (that “t” at the end means sticky bit, aka permissions set to 1777).

The /etc/hosts Gotcha (IPv6 vs IPv4)

This one has caught me before. Sometimes MongoDB fails because localhost points to IPv6 instead of IPv4.

Open /etc/hosts and look for something like this:

::1   localhost localhost.localdomain localhost6 localhost6.localdomain6

If that’s the only localhost entry, you’ll run into issues. Add the IPv4 line back:

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4

::1       localhost localhost.localdomain localhost6 localhost6.localdomain6

Save, restart JetBackup, and you’re good.

Check Port 27217

JetBackup talks to MongoDB on port 27217. Make sure nothing’s blocking it:

nc -v localhost 27217

If you see “Connected,” you’re fine. If you see “Connection refused,” the port’s blocked or MongoDB isn’t listening — time to dig deeper (or get your sysadmin involved).

When All Else Fails: Look at the Logs

Logs don’t lie. Check:

cat /usr/local/jetapps/var/log/mongod/mongod.log

If you spot corruption errors or MongoDB refusing to start properly, the install might be broken. At this point, you’ll probably need to reinstall JetBackup.

Reinstalling JetBackup 5 (Last Resort)

Before wiping it out, save your config exports so you don’t lose everything:

cp /usr/local/jetapps/usr/jetbackup/dailybackup /root/jetbackup

Then remove the packages (for CentOS/CloudLinux/AlmaLinux/Rocky):

yum remove jetbackup5-base jetbackup5-directadmin jetmongod

Reinstall with:

jetapps --install jetbackup5-directadmin stable

Finally, import your config:

jetbackup --import /root/jetbackup/jetbackup5_export_000000.tar.gz

(Replace the filename with your actual export.)

You’ll also need to reindex your destinations:

for id in $(jetbackup5api -F listDestinations | grep '_id: ' | awk '{print $2}'); do 

    jetbackup5api -F reindexDestination -D "_id=$id" ; 

done

It takes a few minutes, but once that’s done, JetBackup should be back in business.

Wrapping It Up

So, what looks like a scary MongoDB connection error usually boils down to a few common issues: services not running, disk space full, wrong localhost config, or port problems. And in the rare case MongoDB is truly corrupted, reinstalling JetBackup fixes it.

The key is to start simple and work your way down the list. Nine times out of ten, you won’t need to reinstall. But it’s good to know that option is there if nothing else works. And here’s the real takeaway: don’t let that giant wall of error text freak you out. With SupportPRO‘s help, you can get JetBackup talking to MongoDB again and your backups running smoothly.