Can't connect to local MongoDB server using MongoJS on Windows

Working with Data Drivers & ODMs
,
1

I’m having difficult getting my NodeJS app to connect to my MongoDB instance. I can connect to the database instance (which I am running locally on my computer, where the data is stored on the D: drive) when I use the shell, but it doesn’t connect when I try to connect it via the app. I was able to get my code to work on a different computer, so I know it’s not the application that’s the issue. When I try to connect to the server to get a simple fetch request from the browser (using http://localhost:5293/getSomeData), my terminal spits out this error and the app closes:

$ node app.js
Server started on port 5293
D:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\utils.js:698
          throw error;
          ^

MongoServerSelectionError: connect ECONNREFUSED ::1:27017
    at Timeout._onTimeout (D:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\core\sdam\topology.js:438:30)
    at listOnTimeout (node:internal/timers:569:17)
    at process.processTimers (node:internal/timers:512:7)
Emitted 'error' event on Database instance at:
    at D:\...\myapp\node_modules\mongojs\lib\database.js:36:16
    at D:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\utils.js:695:9
    at D:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\mongo_client.js:285:23
    at connectCallback (D:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\operations\connect.js:367:5)
    at D:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\operations\connect.js:554:14
    at Object.connectHandler [as callback] (D:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\core\sdam\topology.js:286:11)
    at Timeout._onTimeout (D:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\core\sdam\topology.js:443:25)
    at listOnTimeout (node:internal/timers:569:17)
    at process.processTimers (node:internal/timers:512:7) {
  reason: TopologyDescription {
    type: 'Single',
    setName: null,
    maxSetVersion: null,
    maxElectionId: null,
    servers: Map(1) {
      'localhost:27017' => ServerDescription {
        address: 'localhost:27017',
        error: Error: connect ECONNREFUSED ::1:27017
            at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
          name: 'MongoNetworkError'
        },
        roundTripTime: -1,
        lastUpdateTime: 427883836,
        lastWriteDate: null,
        opTime: null,
        type: 'Unknown',
        topologyVersion: undefined,
        minWireVersion: 0,
        maxWireVersion: 0,
        hosts: [],
        passives: [],
        arbiters: [],
        tags: []
      }
    },
    stale: false,
    compatible: true,
    compatibilityError: null,
    logicalSessionTimeoutMinutes: null,
    heartbeatFrequencyMS: 10000,
    localThresholdMS: 15,
    commonWireVersion: null
  }
}

Node.js v18.16.0

I’ve omitted parts of the filepath for brevity, where there are elipses (…). I’m not sure what to do, as it works on one Windows machine but not the other. I’m using these modules:

mongojs: ^3.1.0
express: ^4.18.2
express-session: ^1.17.3

The version of Node I’m using is 18.16.0. Any help would be much appreciated!

Here is my app that I’m using, if it helps:

dbAccessRouter.js ← Local path: myapp\routers\

const dbAccess = require('express').Router();
const db = require('../db/dbAccess');

dbAccess.get('/', (req, res, next) =>
{
    db.getData(res, next);
}

module.exports = dbAccess;

dbAccess.js ← Local path: myapp\db\

const db = require('mongojs')('userdata', ['users']);

exports.getData() = (res, next) =>
{
    db.users.find({}, (err, found) =>
    {
        console.log(found.length);
		if (err || found.length == 0) 
		{
			next(err || "no data found");
		} 
		else 
		{
			console.log(found);
			res.status(200).json(found);
		}
    }
}

index.js ← My code starts running from here; local path: myapp\

const importExpress = require('express');
const app = importExpress();

app.use(express.json());
const dbAccess = require('./routers/dbAccess');
app.use('/fetch', dbAccess);

app.listen(5293, () =>
{
    console.log("Server started on port 5293");
}
2

Whatever you’re using as a connect string …
Can you use that same connect string from the same host with mongosh and successfully connect?

3

I’m not using a connect string, I think. The closest thing is probably

const db = require('mongojs')('userdata', ['users']);

because I’m using the mongoJS module to connect to my locally hosted server. I can connect to the server using my mongo shell, and it performs CRUD operations that way just fine. I am also able to do the same thing on the other machine where it does work. I’ve mirrored the file structure as closely as I can between the two, and they all have the same modules (and versions of them) installed, so I’m fairly certain it’s not the code itself. The only differences I have are that the machine where it does work (call it machine A) is that it uses MongoDB version 5.0.9, where as the machine where it doesn’t work (call it machine B) is using MongoDB version 5.0.18. I’ve tried using different browsers too (such as Firefox, Chrome) but nothing I do seems to make it work on machine B. I try typing in localhost:5293/fetch but the page just times out and the app crashes because it can’t connect to the local server.

4

So you use the same connection string for both?

const mongojs = require('mongojs')
const db = mongojs(connectionString, [collections])

Taking a wild guess, I’d say your mongod is not listening on the interface thru which your code is trying to connect. Check your mongod configuration.

5

Yes, the connection string is exactly the same on both machines. However, on machine B, the MongoDB libraries are stored on my C: drive, while the data itself is on my D: drive at D:\data\db (my C: drive on machine B is quite small unfortunately). On machine A, everything is on the C: drive.

I checked my MongoDB configuration, here is what it says for machine B:

> db.serverCmdLineOpts()
{
        "argv" : [
                "C:\\Program Files\\MongoDB\\Server\\5.0\\bin\\mongod.exe",
                "--config",
                "C:\\Program Files\\MongoDB\\Server\\5.0\\bin\\mongod.cfg",
                "--service"
        ],
        "parsed" : {
                "config" : "C:\\Program Files\\MongoDB\\Server\\5.0\\bin\\mongod.cfg",
                "net" : {
                        "bindIp" : "127.0.0.1",
                        "port" : 27017
                },
                "service" : true,
                "storage" : {
                        "dbPath" : "C:\\Program Files\\MongoDB\\Server\\5.0\\data",
                        "journal" : {
                                "enabled" : true
                        }
                },
                "systemLog" : {
                        "destination" : "file",
                        "logAppend" : true,
                        "path" : "C:\\Program Files\\MongoDB\\Server\\5.0\\log\\mongod.log"
                }
        },
        "ok" : 1
}

In contrast to machine A, this is what it says:

> db.serverCmdLineOpts()
{
        "argv" : [
                "C:\\Program Files\\MongoDB\\Server\\5.0\\bin\\mongod.exe"
        ],
        "parsed" : {
                
        },
        "ok" : 1
}

I suppose this brings me closer to finding out what the problem is (or maybe this is the problem) but I’m not sure what to do to fix it. I don’t want to break MongoDB.

Side note: It also seems like the data is being stored (on machine B) at C:\Program Files\MongoDB\Server\5.0\data\? Although, the folder D:\data\db\ isn’t empty either, and their contents look very similar.

6

Does it have anything to do with trying to bind via IPv6? I see the failure talking about ::1

7

No, I don’t think so. Here’s the contents of the mongod.cfg file:

# mongod.conf

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

# Where and how to store data.
storage:
  dbPath: C:\Program Files\MongoDB\Server\5.0\data
  journal:
    enabled: true
#  engine:
#  wiredTiger:

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path:  C:\Program Files\MongoDB\Server\5.0\log\mongod.log

# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1


#processManagement:

#security:

#operationProfiling:

#replication:

#sharding:

## Enterprise-Only Options:

#auditLog:

#snmp:

When I boot up the server on machine B, it doesn’t mention anything about IPv6 binding. There’s a single message that says it’s bound to localhost, and that the server is closed to remote connections. You can Ctrl+F for the line by typing “This server is bound to localhost” for the exact message.

$ mongod
{"t":{"$date":"2023-06-21T17:06:50.441-04:00"},"s":"I",  "c":"CONTROL",  "id":23285,   "ctx":"thread1","msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"}
{"t":{"$date":"2023-06-21T17:06:50.442-04:00"},"s":"I",  "c":"NETWORK",  "id":4915701, "ctx":"thread1","msg":"Initialized wire specification","attr":{"spec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":13},"incomingInternalClient":{"minWireVersion":0,"maxWireVersion":13},"outgoing":{"minWireVersion":0,"maxWireVersion":13},"isInternalClient":true}}}
{"t":{"$date":"2023-06-21T17:06:50.443-04:00"},"s":"W",  "c":"ASIO",     "id":22601,   "ctx":"thread1","msg":"No TransportLayer configured during NetworkInterface startup"}
{"t":{"$date":"2023-06-21T17:06:50.443-04:00"},"s":"I",  "c":"NETWORK",  "id":4648602, "ctx":"thread1","msg":"Implicit TCP FastOpen in use."}
{"t":{"$date":"2023-06-21T17:06:50.444-04:00"},"s":"W",  "c":"ASIO",     "id":22601,   "ctx":"thread1","msg":"No TransportLayer configured during NetworkInterface startup"}
{"t":{"$date":"2023-06-21T17:06:50.445-04:00"},"s":"I",  "c":"REPL",     "id":5123008, "ctx":"thread1","msg":"Successfully registered PrimaryOnlyService","attr":{"service":"TenantMigrationDonorService","ns":"config.tenantMigrationDonors"}}
{"t":{"$date":"2023-06-21T17:06:50.445-04:00"},"s":"I",  "c":"REPL",     "id":5123008, "ctx":"thread1","msg":"Successfully registered PrimaryOnlyService","attr":{"service":"TenantMigrationRecipientService","ns":"config.tenantMigrationRecipients"}}  
{"t":{"$date":"2023-06-21T17:06:50.445-04:00"},"s":"I",  "c":"CONTROL",  "id":5945603, "ctx":"thread1","msg":"Multi threading initialized"}
{"t":{"$date":"2023-06-21T17:06:50.446-04:00"},"s":"I",  "c":"CONTROL",  "id":4615611, "ctx":"initandlisten","msg":"MongoDB starting","attr":{"pid":16892,"port":27017,"dbPath":"D:/data/db/","architecture":"64-bit","host":"Infinity"}}
{"t":{"$date":"2023-06-21T17:06:50.446-04:00"},"s":"I",  "c":"CONTROL",  "id":23398,   "ctx":"initandlisten","msg":"Target operating system minimum version","attr":{"targetMinOS":"Windows 7/Windows Server 2008 R2"}}
{"t":{"$date":"2023-06-21T17:06:50.447-04:00"},"s":"I",  "c":"CONTROL",  "id":23403,   "ctx":"initandlisten","msg":"Build Info","attr":{"buildInfo":{"version":"5.0.18","gitVersion":"796abe56bfdbca6968ff570311bf72d93632825b","modules":[],"allocator":"tcmalloc","environment":{"distmod":"windows","distarch":"x86_64","target_arch":"x86_64"}}}}
{"t":{"$date":"2023-06-21T17:06:50.447-04:00"},"s":"I",  "c":"CONTROL",  "id":51765,   "ctx":"initandlisten","msg":"Operating System","attr":{"os":{"name":"Microsoft Windows 10","version":"10.0 (build 19045)"}}}
{"t":{"$date":"2023-06-21T17:06:50.447-04:00"},"s":"I",  "c":"CONTROL",  "id":21951,   "ctx":"initandlisten","msg":"Options set by command line","attr":{"options":{}}}
{"t":{"$date":"2023-06-21T17:06:50.449-04:00"},"s":"I",  "c":"STORAGE",  "id":22270,   "ctx":"initandlisten","msg":"Storage engine to use detected by data files","attr":{"dbpath":"D:/data/db/","storageEngine":"wiredTiger"}}
{"t":{"$date":"2023-06-21T17:06:50.449-04:00"},"s":"I",  "c":"STORAGE",  "id":22315,   "ctx":"initandlisten","msg":"Opening WiredTiger","attr":{"config":"create,cache_size=15806M,session_max=33000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),builtin_extension_config=(zstd=(compression_level=6)),file_manager=(close_idle_time=600,close_scan_interval=10,close_handle_minimum=250),statistics_log=(wait=0),verbose=[recovery_progress,checkpoint_progress,compact_progress],"}}
{"t":{"$date":"2023-06-21T17:06:50.575-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1687381610:574669][16892:140714226965296], txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 10 through 11"}}
{"t":{"$date":"2023-06-21T17:06:50.623-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1687381610:622685][16892:140714226965296], txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 11 through 11"}}
{"t":{"$date":"2023-06-21T17:06:50.681-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1687381610:681696][16892:140714226965296], txn-recover: [WT_VERB_RECOVERY_ALL] Main recovery 
loop: starting at 10/6400 to 11/256"}}
{"t":{"$date":"2023-06-21T17:06:50.773-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1687381610:773772][16892:140714226965296], txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 10 through 11"}}
{"t":{"$date":"2023-06-21T17:06:50.874-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1687381610:873806][16892:140714226965296], txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 11 through 11"}}
{"t":{"$date":"2023-06-21T17:06:50.920-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1687381610:920697][16892:140714226965296], txn-recover: [WT_VERB_RECOVERY_ALL] Set global recovery timestamp: (0, 0)"}}
{"t":{"$date":"2023-06-21T17:06:50.921-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1687381610:920697][16892:140714226965296], txn-recover: [WT_VERB_RECOVERY_ALL] Set global oldest timestamp: (0, 0)"}}
{"t":{"$date":"2023-06-21T17:06:50.923-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1687381610:922689][16892:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 1, snapshot max: 1 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 3181"}}
{"t":{"$date":"2023-06-21T17:06:51.067-04:00"},"s":"I",  "c":"STORAGE",  "id":4795906, "ctx":"initandlisten","msg":"WiredTiger opened","attr":{"durationMillis":618}}
{"t":{"$date":"2023-06-21T17:06:51.067-04:00"},"s":"I",  "c":"RECOVERY", "id":23987,   "ctx":"initandlisten","msg":"WiredTiger recoveryTimestamp","attr":{"recoveryTimestamp":{"$timestamp":{"t":0,"i":0}}}}
{"t":{"$date":"2023-06-21T17:06:51.071-04:00"},"s":"I",  "c":"STORAGE",  "id":22262,   "ctx":"initandlisten","msg":"Timestamp monitor starting"}
{"t":{"$date":"2023-06-21T17:06:51.148-04:00"},"s":"W",  "c":"CONTROL",  "id":22120,   "ctx":"initandlisten","msg":"Access control is not enabled for the database. Read and write access to data and configuration is unrestricted","tags":["startupWarnings"]}
{"t":{"$date":"2023-06-21T17:06:51.149-04:00"},"s":"W",  "c":"CONTROL",  "id":22140,   "ctx":"initandlisten","msg":"This server is bound to localhost. Remote systems will be unable to connect to this server. Start the server with --bind_ip <address> to specify which IP addresses it should serve responses from, or with --bind_ip_all to bind to all interfaces. If this behavior is desired, start the server with --bind_ip 127.0.0.1 to disable this warning","tags":["startupWarnings"]}
{"t":{"$date":"2023-06-21T17:06:51.152-04:00"},"s":"I",  "c":"NETWORK",  "id":4915702, "ctx":"initandlisten","msg":"Updated wire specification","attr":{"oldSpec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":13},"incomingInternalClient":{"minWireVersion":0,"maxWireVersion":13},"outgoing":{"minWireVersion":0,"maxWireVersion":13},"isInternalClient":true},"newSpec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":13},"incomingInternalClient":{"minWireVersion":13,"maxWireVersion":13},"outgoing":{"minWireVersion":13,"maxWireVersion":13},"isInternalClient":true}}}
{"t":{"$date":"2023-06-21T17:06:51.153-04:00"},"s":"I",  "c":"STORAGE",  "id":5071100, "ctx":"initandlisten","msg":"Clearing temp directory"}
{"t":{"$date":"2023-06-21T17:06:51.154-04:00"},"s":"I",  "c":"CONTROL",  "id":20536,   "ctx":"initandlisten","msg":"Flow Control is enabled on this deployment"}
{"t":{"$date":"2023-06-21T17:06:51.493-04:00"},"s":"I",  "c":"FTDC",     "id":20625,   "ctx":"initandlisten","msg":"Initializing full-time diagnostic data capture","attr":{"dataDirectory":"D:/data/db/diagnostic.data"}}
{"t":{"$date":"2023-06-21T17:06:51.496-04:00"},"s":"I",  "c":"REPL",     "id":6015317, "ctx":"initandlisten","msg":"Setting new configuration state","attr":{"newState":"ConfigReplicationDisabled","oldState":"ConfigPreStart"}}
{"t":{"$date":"2023-06-21T17:06:51.498-04:00"},"s":"I",  "c":"NETWORK",  "id":23015,   "ctx":"listener","msg":"Listening on","attr":{"address":"127.0.0.1"}}
{"t":{"$date":"2023-06-21T17:06:51.498-04:00"},"s":"I",  "c":"NETWORK",  "id":23016,   "ctx":"listener","msg":"Waiting for connections","attr":{"port":27017,"ssl":"off"}}
{"t":{"$date":"2023-06-21T17:07:51.151-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687381671:151157][16892:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 3, snapshot max: 3 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 3181"}}
{"t":{"$date":"2023-06-21T17:08:51.349-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687381731:348965][16892:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 6, snapshot max: 6 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 3181"}}
{"t":{"$date":"2023-06-21T17:09:51.505-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687381791:505566][16892:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 8, snapshot max: 8 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 3181"}}
{"t":{"$date":"2023-06-21T17:10:51.671-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687381851:671204][16892:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 10, snapshot max: 10 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 3181"}}
{"t":{"$date":"2023-06-21T17:11:51.795-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687381911:794859][16892:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 12, snapshot max: 12 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 3181"}}
{"t":{"$date":"2023-06-21T17:12:51.953-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687381971:953133][16892:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 14, snapshot max: 14 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 3181"}}
{"t":{"$date":"2023-06-21T17:13:52.092-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687382032:92101][16892:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 16, snapshot max: 16 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 3181"}}
{"t":{"$date":"2023-06-21T17:14:52.299-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687382092:299761][16892:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 18, snapshot max: 18 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 3181"}}
{"t":{"$date":"2023-06-21T17:15:52.465-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687382152:464879][16892:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 20, snapshot max: 20 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 3181"}}

I’ve tried modifying the .cfg file by removing all the networking stuff, so it looks like this:

# mongod.conf

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

# Where and how to store data.
storage:
  dbPath: C:\Program Files\MongoDB\Server\5.0\data
  journal:
    enabled: true
#  engine:
#  wiredTiger:

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path:  C:\Program Files\MongoDB\Server\5.0\log\mongod.log

# network interfaces

#processManagement:

#security:

#operationProfiling:

#replication:

#sharding:

## Enterprise-Only Options:

#auditLog:

#snmp:

…but it doesn’t seem to do anything, as when I close the server, reboot it, and run the db.serverCmdLineOpts(), it still says that the bound IP address is 127.0.0.1, with port 27017.

8

Nothing funny in the logs?

9

I hadn’t thought of that. Here’s the log from C:\Program Files\MongoDB\Server\5.0\log\ for when I connect to the server using a shell:

{"t":{"$date":"2023-06-21T17:48:38.568-04:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"127.0.0.1:53174","uuid":"ec452de0-f4c0-4a91-94b5-b6614cb2a356","connectionId":15,"connectionCount":1}}
{"t":{"$date":"2023-06-21T17:48:38.569-04:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn15","msg":"client metadata","attr":{"remote":"127.0.0.1:53174","client":"conn15","doc":{"application":{"name":"MongoDB Shell"},"driver":{"name":"MongoDB Internal Client","version":"5.0.18"},"os":{"type":"Windows","name":"Microsoft Windows 10","architecture":"x86_64","version":"10.0 (build 19045)"}}}}
{"t":{"$date":"2023-06-21T17:48:44.980-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687384124:980516][5476:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 10679, snapshot max: 10679 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 5806"}}
{"t":{"$date":"2023-06-21T17:48:53.200-04:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn15","msg":"Connection ended","attr":{"remote":"127.0.0.1:53174","uuid":"ec452de0-f4c0-4a91-94b5-b6614cb2a356","connectionId":15,"connectionCount":0}}

I just connect to the server, and then exit immediately to get an idea of what it might put in the log. I then try to connect via the app, and this is what got added after the four lines above:

{"t":{"$date":"2023-06-21T17:49:45.000-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687384185:11][5476:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 10681, snapshot max: 10681 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 5806"}}
{"t":{"$date":"2023-06-21T17:50:45.019-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687384245:19677][5476:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 10683, snapshot max: 10683 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 5806"}}
{"t":{"$date":"2023-06-21T17:51:45.038-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687384305:38178][5476:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 10685, snapshot max: 10685 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 5806"}}

Just some checkpoints where it saves a snapshot of the server, I assume. So no, I guess there’s nothing funny in the logs. I guess the server isn’t even recognizing that a local client is trying to connect to localhost. The rest of the log file is the same stuff: saving snapshots, and connections to the server by the shell.

10

Small update: I was able to check the mongod.cfg on machine A. The configuration file is the exact same as machine B, although when I run db.serverCmdLineOpts() in the shell nothing shows up, as I have shown above. But the CFG is the same, and I am able to connect to it using my app, using a web browser on the same machine (putting localhost:5298/fetch in the URL bar). Strangely, the log file does not log anything, despite my connections to the server, or spinning it up. The last log from the server on machine A was 2 days ago, on 2023-06-19. It notes some activities, like me inserting documents into the database via mongo shell, but nothing out of the ordinary, and nothing about connecting to the server (I had made the app just yesterday on 2023-06-20, so of course there wouldn’t be any logs about connecting when the last log is from the day before that).

11

I’ve tried using a database on the C: drive, but unfortunately that didn’t seem to work either. I think it’s important that I mention that when I made a C:\data\db drive, MongoDB seems to have been smart enough to clone the database from my D: drive. Yet, for some reason my app still refuses to connect to the database on machine B. I feel like this shouldn’t be something difficult to get working, yet it is.

12

You could try a re-install from scratch

13

Last time I installed it as a service on machine B. This time I installed it without a service, and I also did not install Mongo Compass. Here is what I got from running the same command to check the configuration options:

> db.serverCmdLineOpts()
{
        "argv" : [
                "C:\\Program Files\\MongoDB\\Server\\5.0\\bin\\mongod.exe"
        ],
        "parsed" : {

        },
        "ok" : 1
}

Okay, that looks good. It certainly looks like what was on machine A. I was also able to start the service on my D: drive, and I could also perform CRUD operations via the mongo shell.

Here are the logs:

{"t":{"$date":"2023-06-22T21:03:15.520-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687482195:519814][5476:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 13947, snapshot max: 13947 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 5806"}}
{"t":{"$date":"2023-06-22T21:04:15.538-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687482255:537953][5476:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 13949, snapshot max: 13949 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 5806"}}
{"t":{"$date":"2023-06-22T21:05:15.559-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":"[1687482315:558758][5476:140714226965296], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 13951, snapshot max: 13951 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 5806"}}
{"t":{"$date":"2023-06-22T21:05:31.248-04:00"},"s":"I",  "c":"CONTROL",  "id":23315,   "ctx":"serviceShutdown","msg":"Received request from Windows Service Control Manager","attr":{"code":"SERVICE_CONTROL_STOP","inShutdown":"false"}}
{"t":{"$date":"2023-06-22T21:05:31.248-04:00"},"s":"I",  "c":"REPL",     "id":4784900, "ctx":"serviceShutdown","msg":"Stepping down the ReplicationCoordinator for shutdown","attr":{"waitTimeMillis":15000}}
{"t":{"$date":"2023-06-22T21:05:31.248-04:00"},"s":"I",  "c":"REPL",     "id":4794602, "ctx":"serviceShutdown","msg":"Attempting to enter quiesce mode"}
{"t":{"$date":"2023-06-22T21:05:31.248-04:00"},"s":"I",  "c":"COMMAND",  "id":4784901, "ctx":"serviceShutdown","msg":"Shutting down the MirrorMaestro"}
{"t":{"$date":"2023-06-22T21:05:31.248-04:00"},"s":"I",  "c":"SHARDING", "id":4784902, "ctx":"serviceShutdown","msg":"Shutting down the WaitForMajorityService"}
{"t":{"$date":"2023-06-22T21:05:31.249-04:00"},"s":"I",  "c":"CONTROL",  "id":4784903, "ctx":"serviceShutdown","msg":"Shutting down the LogicalSessionCache"}
{"t":{"$date":"2023-06-22T21:05:31.249-04:00"},"s":"I",  "c":"NETWORK",  "id":20562,   "ctx":"serviceShutdown","msg":"Shutdown: going to close listening sockets"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"NETWORK",  "id":4784905, "ctx":"serviceShutdown","msg":"Shutting down the global connection pool"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"CONTROL",  "id":4784906, "ctx":"serviceShutdown","msg":"Shutting down the FlowControlTicketholder"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"-",        "id":20520,   "ctx":"serviceShutdown","msg":"Stopping further Flow Control ticket acquisitions."}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"CONTROL",  "id":4784908, "ctx":"serviceShutdown","msg":"Shutting down the PeriodicThreadToAbortExpiredTransactions"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"REPL",     "id":4784909, "ctx":"serviceShutdown","msg":"Shutting down the ReplicationCoordinator"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"SHARDING", "id":4784910, "ctx":"serviceShutdown","msg":"Shutting down the ShardingInitializationMongoD"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"REPL",     "id":4784911, "ctx":"serviceShutdown","msg":"Enqueuing the ReplicationStateTransitionLock for shutdown"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"-",        "id":4784912, "ctx":"serviceShutdown","msg":"Killing all operations for shutdown"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"-",        "id":4695300, "ctx":"serviceShutdown","msg":"Interrupted all currently running operations","attr":{"opsKilled":3}}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"TENANT_M", "id":5093807, "ctx":"serviceShutdown","msg":"Shutting down all TenantMigrationAccessBlockers on global shutdown"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"COMMAND",  "id":4784913, "ctx":"serviceShutdown","msg":"Shutting down all open transactions"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"REPL",     "id":4784914, "ctx":"serviceShutdown","msg":"Acquiring the ReplicationStateTransitionLock for shutdown"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"INDEX",    "id":4784915, "ctx":"serviceShutdown","msg":"Shutting down the IndexBuildsCoordinator"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"REPL",     "id":4784916, "ctx":"serviceShutdown","msg":"Reacquiring the ReplicationStateTransitionLock for shutdown"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"REPL",     "id":4784917, "ctx":"serviceShutdown","msg":"Attempting to mark clean shutdown"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"NETWORK",  "id":4784918, "ctx":"serviceShutdown","msg":"Shutting down the ReplicaSetMonitor"}
{"t":{"$date":"2023-06-22T21:05:31.250-04:00"},"s":"I",  "c":"SHARDING", "id":4784921, "ctx":"serviceShutdown","msg":"Shutting down the MigrationUtilExecutor"}
{"t":{"$date":"2023-06-22T21:05:31.251-04:00"},"s":"I",  "c":"ASIO",     "id":22582,   "ctx":"MigrationUtil-TaskExecutor","msg":"Killing all outstanding egress activity."}
{"t":{"$date":"2023-06-22T21:05:31.251-04:00"},"s":"I",  "c":"COMMAND",  "id":4784923, "ctx":"serviceShutdown","msg":"Shutting down the ServiceEntryPoint"}
{"t":{"$date":"2023-06-22T21:05:31.251-04:00"},"s":"I",  "c":"CONTROL",  "id":4784925, "ctx":"serviceShutdown","msg":"Shutting down free monitoring"}
{"t":{"$date":"2023-06-22T21:05:31.251-04:00"},"s":"I",  "c":"CONTROL",  "id":20609,   "ctx":"serviceShutdown","msg":"Shutting down free monitoring"}
{"t":{"$date":"2023-06-22T21:05:31.251-04:00"},"s":"I",  "c":"CONTROL",  "id":4784927, "ctx":"serviceShutdown","msg":"Shutting down the HealthLog"}
{"t":{"$date":"2023-06-22T21:05:31.251-04:00"},"s":"I",  "c":"CONTROL",  "id":4784928, "ctx":"serviceShutdown","msg":"Shutting down the TTL monitor"}
{"t":{"$date":"2023-06-22T21:05:31.251-04:00"},"s":"I",  "c":"INDEX",    "id":3684100, "ctx":"serviceShutdown","msg":"Shutting down TTL collection monitor thread"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"INDEX",    "id":3684101, "ctx":"serviceShutdown","msg":"Finished shutting down TTL collection monitor thread"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"CONTROL",  "id":4784929, "ctx":"serviceShutdown","msg":"Acquiring the global lock for shutdown"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"CONTROL",  "id":4784930, "ctx":"serviceShutdown","msg":"Shutting down the storage engine"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"STORAGE",  "id":22320,   "ctx":"serviceShutdown","msg":"Shutting down journal flusher thread"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"STORAGE",  "id":22321,   "ctx":"serviceShutdown","msg":"Finished shutting down journal flusher thread"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"STORAGE",  "id":22322,   "ctx":"serviceShutdown","msg":"Shutting down checkpoint thread"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"STORAGE",  "id":22323,   "ctx":"serviceShutdown","msg":"Finished shutting down checkpoint thread"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"STORAGE",  "id":20282,   "ctx":"serviceShutdown","msg":"Deregistering all the collections"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"STORAGE",  "id":22261,   "ctx":"serviceShutdown","msg":"Timestamp monitor shutting down"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"STORAGE",  "id":22317,   "ctx":"serviceShutdown","msg":"WiredTigerKVEngine shutting down"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"STORAGE",  "id":22318,   "ctx":"serviceShutdown","msg":"Shutting down session sweeper thread"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"STORAGE",  "id":22319,   "ctx":"serviceShutdown","msg":"Finished shutting down session sweeper thread"}
{"t":{"$date":"2023-06-22T21:05:31.252-04:00"},"s":"I",  "c":"STORAGE",  "id":4795902, "ctx":"serviceShutdown","msg":"Closing WiredTiger","attr":{"closeConfig":"leak_memory=true,"}}
{"t":{"$date":"2023-06-22T21:05:31.253-04:00"},"s":"I",  "c":"STORAGE",  "id":22430,   "ctx":"serviceShutdown","msg":"WiredTiger message","attr":{"message":"[1687482331:253275][5476:140714226965296], close_ckpt: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 13953, snapshot max: 13953 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 5806"}}
{"t":{"$date":"2023-06-22T21:05:31.285-04:00"},"s":"I",  "c":"STORAGE",  "id":4795901, "ctx":"serviceShutdown","msg":"WiredTiger closed","attr":{"durationMillis":33}}
{"t":{"$date":"2023-06-22T21:05:31.285-04:00"},"s":"I",  "c":"STORAGE",  "id":22281,   "ctx":"serviceShutdown","msg":"shutdown: removing fs lock..."}
{"t":{"$date":"2023-06-22T21:05:31.285-04:00"},"s":"I",  "c":"-",        "id":4784931, "ctx":"serviceShutdown","msg":"Dropping the scope cache for shutdown"}
{"t":{"$date":"2023-06-22T21:05:31.285-04:00"},"s":"I",  "c":"FTDC",     "id":4784926, "ctx":"serviceShutdown","msg":"Shutting down full-time data capture"}
{"t":{"$date":"2023-06-22T21:05:31.285-04:00"},"s":"I",  "c":"FTDC",     "id":20626,   "ctx":"serviceShutdown","msg":"Shutting down full-time diagnostic data capture"}
{"t":{"$date":"2023-06-22T21:05:31.289-04:00"},"s":"I",  "c":"CONTROL",  "id":20565,   "ctx":"serviceShutdown","msg":"Now exiting"}

In short, it doesn’t log anything much anymore. The entries in here coincide with me trying to start the server without having created D:\data\db first (I deleted it to get as clean a slate as possible). But whenever I log in via the shell, the server doesn’t log it anymore, also like on machine A.

Here are also the configuration files.

# mongod.conf

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

# Where and how to store data.
storage:
  dbPath: %MONGO_DATA_PATH%
  journal:
    enabled: true
#  engine:
#  wiredTiger:

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path:  %MONGO_LOG_PATH%\mongod.log

# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1


#processManagement:

#security:

#operationProfiling:

#replication:

#sharding:

## Enterprise-Only Options:

#auditLog:

#snmp:

The only thing that seems to have changed between installations is that the dbPath isn’t explicit anymore, and neither is the path for systemLog.path. For reference, the path of the log above is C:\Program Files\MongoDB\Server\5.0\log\.

Unfortunately, despite reinstalling it, my app still fails to connect to the server.

14

I’ve tried using a database on the C: drive. I made a new \data\db folder, and unlike before, it did not seem to copy the databases on my D: drive. That’s interesting. But my app still failed to connect to the server.

So then I tried using both a database on the C: drive, and starting the project from the C: drive. I copied all the project files over, and started the server. This did not work either. Here’s the output:

$ node app.js
Server started on port 5293
Attempting GET request
C:\Users\Mingtendo\Documents\ExpressCode\myapp\node_modules\mongojs\node_modules\mongodb\lib\utils.js:698
          throw error;
          ^

MongoServerSelectionError: connect ECONNREFUSED ::1:27017
    at Timeout._onTimeout (C:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\core\sdam\topology.js:438:30)
    at listOnTimeout (node:internal/timers:569:17)
    at process.processTimers (node:internal/timers:512:7)
Emitted 'error' event on Database instance at:
    at C:\...\myapp\node_modules\mongojs\lib\database.js:36:16
    at C:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\utils.js:695:9
    at C:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\mongo_client.js:285:23
    at connectCallback (C:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\operations\connect.js:367:5)
    at C:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\operations\connect.js:554:14
    at Object.connectHandler [as callback] (C:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\core\sdam\topology.js:286:11)
    at Timeout._onTimeout (C:\...\myapp\node_modules\mongojs\node_modules\mongodb\lib\core\sdam\topology.js:443:25)
    at listOnTimeout (node:internal/timers:569:17)
    at process.processTimers (node:internal/timers:512:7) {
  reason: TopologyDescription {
    type: 'Single',
    setName: null,
    maxSetVersion: null,
    maxElectionId: null,
    servers: Map(1) {
      'localhost:27017' => ServerDescription {
        address: 'localhost:27017',
        error: Error: connect ECONNREFUSED ::1:27017
            at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
          name: 'MongoNetworkError'
        },
        roundTripTime: -1,
        lastUpdateTime: 2832971,
        lastWriteDate: null,
        opTime: null,
        type: 'Unknown',
        topologyVersion: undefined,
        minWireVersion: 0,
        maxWireVersion: 0,
        hosts: [],
        passives: [],
        arbiters: [],
        tags: []
      }
    },
    stale: false,
    compatible: true,
    compatibilityError: null,
    logicalSessionTimeoutMinutes: null,
    heartbeatFrequencyMS: 10000,
    localThresholdMS: 15,
    commonWireVersion: null
  }
}

Node.js v18.16.0

I replaced some of the filepath with elipses for brevity. It’s the exact same error. I’m starting to think that perhaps there’s something with my firewall? Or perhaps I still didn’t install it correctly? I don’t understand why it works on machine A, yet not on machine B. Maybe I need to use version 5.0.9, since 5.0.18 has issues?

15

I installed MongoDB version 5.0.9 from the archives. You have to navigate to the actual path of the executable to run it via the terminal, but it worked, and my old data was preserved. I ran it on my D: drive, but it still wouldn’t connect. At this point, I decided to go into my firewall settings. I opened Windows Defender Firewall and added the mongod.exe executable to the list of allowed apps. I also noticed that not all of my node.exe apps were checked? So just for testing sake I marked them as checked too. Unfortunately, that did not work either. I’m not sure what else I can do at this point to make it work. Perhaps I can just try using the latest stable version of MongoDB. I just wish it wasn’t this difficult.

16

Good news! I have found a solution. I found a Reddit page that mentioned trying IPv6. In case the Reddit comment gets deleted, I’ll put this here:

Crypt0n95

·11 mo. ago

Are you sure your mongodb is listening on the ipv6 interface of your loopback device? If I remember correctly, mongod is not listening on ipv6 interfaces by default. I am not familiar with the JS driver but trying to connect via IPv6 seems odd to me too.

Try using the IPv4 address of you loopback device explicitly by changing “localhost” to “127.0.0.1” in your connection string.

OR

Make sure mongod is listening on IPv6 addresses too.

However, this is a workaround, since it works on machine A (although I have no idea how MongoDB was installed on machine A because I didn’t do it myself). Is there a way to set up MongoDB without having to type mongod --ipv6 everytime?

1 Like
17

I had the same issue after i updated to Nodejs 18

18

@Tarun_Gaur do you have any help on this problem?

19

I looked at the documentation and found that you should be able to enable IPv6 support by default by setting the proper commands. So, I went into the my mongo.cfg file stored in the same place on my C: drive, and put this in it:

# mongod.conf

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

# Where and how to store data.
storage:
  dbPath: %MONGO_DATA_PATH%
  journal:
    enabled: true
#  engine:
#  wiredTiger:

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path:  %MONGO_LOG_PATH%\mongod.log

# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1, ::1
  ipv6: true


#processManagement:

#security:

#operationProfiling:

#replication:

#sharding:

## Enterprise-Only Options:

#auditLog:

#snmp:

At least to my knowledge, ::1 is the localhost for IPv6. I also set the IPv6 boolean to true. However, when I start the server by using mongod, I am unable to connect to the server from my app. However, doing mongod --ipv6 still works. I’m confused as to why this didn’t work, because I’m pretty sure I enabled everything I needed to to have IPv6 support by ‘default’ without needing to specify any arguments when spinning up the server. I did a db.serverCmdLineOpts() when I started it after the CFG file modification, and it spit out this:

> db.serverCmdLineOpts()
{
        "argv" : [
                "C:\\Program Files\\MongoDB\\Server\\5.0\\bin\\mongod.exe"
        ],
        "parsed" : {

        },
        "ok" : 1
}
> exit;

…which does look like what was on machine A. To be clear, I did not install MongoDB as a Windows service this time, so that’s probably why, as before (you can check in Post #4) the “argv” had some commands in it relating to service options. Perhaps the CFG file is only read if you install MongoDB as a service?

Furthermore, on machine A the connection to the server via the app worked just fine without me needing to specify IPv6 support (in the CFG file or as an argument), and I used NodeJS version 18.15 on it. I’ll still want to figure out why MongoDB performs so differently between the two, but right now I at least want the configuration file to work, which it doesn’t.