Processes, Ports, Data Directories, Connection Strings, Databases, and Collections

Learning outcomes

After installation, troubleshooting becomes much easier when every name in a connection string maps to an observable runtime object. AtlasMart developers should be able to answer: Which process owns port 27017? Which address is it bound to? Where is its data? Which server did the URI reach? When does a database or collection actually exist?

1. Process, listener, and port are related but not identical concepts

A running mongod process owns one or more listening endpoints. MongoDB's default client port for mongod and mongos is 27017, but the port is configurable. The server also has a bind address: the interfaces on which it accepts traffic. Self-managed MongoDB binaries bind to localhost by default. Changing the port does not change the bind policy, and changing the bind policy does not enable authentication.

This lesson starts its own disposable server so it remains reproducible after earlier lessons are cleaned up. Inside the container, mongod listens on port 27017; Docker publishes that container port to 127.0.0.1:27018 on the host. The URI therefore points at host port 27018. This is why “port 27017 is open” is incomplete—you must identify which interface, namespace, and process.

docker run --name atlasmart-mongo-l4   -p 127.0.0.1:27018:27017   -v atlasmart-l4-data:/data/db   -d mongodb/mongodb-community-server:8.3.8-ubuntu2204-slimdocker ps --filter name=atlasmart-mongo-l4docker port atlasmart-mongo-l4 27017docker inspect atlasmart-mongo-l4 --format "{{json .NetworkSettings.Ports}}"

Native OS listener checks vary: on Windows PowerShell you can use Get-NetTCPConnection -LocalPort 27017; on Linux ss -ltnp is common; on macOS lsof -nP -iTCP:27017 -sTCP:LISTEN is common. These are diagnostic examples, not requirements.

2. Connection strings encode discovery, credentials, and options

MongoDB supports a standard URI beginning mongodb:// and a DNS seed-list/SRV format beginning mongodb+srv://. The standard form names hosts explicitly. The SRV form lets DNS provide seed hosts and simplifies managed-cluster rotation; current MongoDB documentation recommends SRV when possible for compatible clustered deployments.

# Local standalone: explicit host/port, no authentication in Lessons 1-4mongodb://127.0.0.1:27018/?directConnection=true# Authenticated local user created in the atlasmart database (Lesson 5 shape)mongodb://atlasApp:<password>@127.0.0.1:27018/atlasmart?authSource=atlasmart&directConnection=true# Managed SRV shape; obtain the actual host from Atlasmongodb+srv://<user>:<password>@<cluster-host>/atlasmart

directConnection=true is appropriate for this single standalone endpoint because the client should not perform replica-set discovery. In later replica-set lessons, the correct URI names the replica set and multiple discoverable members (or SRV seeds) rather than forcing a direct connection to one member.

If a username/password contains URI-reserved characters such as @, :, /, or #, those characters must be percent-encoded when embedded in the URI. Prefer not to embed passwords in examples at all.

3. Data directories and configuration must be inspected, not assumed

Native package installations choose data/log paths according to OS and package conventions. Containers add another layer: the official Community image declares data volumes under /data/db and /data/configdb. The most robust course habit is to ask the running server for parsed command-line/configuration state and ask Docker for mount state.

db.adminCommand({ getCmdLineOpts: 1 })

docker inspect atlasmart-mongo-l4 --format "{{json .Mounts}}"

A path printed by the container is a container path, not necessarily a host path. A named volume may be stored in a Docker-managed location that should not be edited directly. Treat the database files as storage-engine state, not as JSON files to open and modify.

4. Database and collection names are logical namespaces

Running use atlasmart in mongosh changes the shell's current database handle; it does not necessarily persist a new database by itself. A collection can be created explicitly or implicitly by a write when permitted. To prove what exists, inspect metadata after the write.

use atlasmartshow collectionsdb.orders.insertOne({  orderId: "o-1001",  customerId: "c-17",  status: "created",  createdAt: new Date()})db.runCommand({ listCollections: 1, nameOnly: true })db.getSiblingDB("admin").runCommand({ listDatabases: 1, nameOnly: true })

The inserted document creates observable collection state. The list commands then provide metadata evidence. This is more reliable than treating the shell prompt as proof that a database exists.

5. Deliberately wrong approaches and their failure signals

6. A reproducible runtime-evidence lab

The dedicated Chapter 01 container is already running on host port 27018. Capture its state, then deliberately try the wrong host port to learn the difference between a server problem and an endpoint-selection problem.

docker ps --filter name=atlasmart-mongo-l4docker port atlasmart-mongo-l4 27017docker inspect atlasmart-mongo-l4 --format "{{json .Mounts}}"mongosh "mongodb://127.0.0.1:27018/?directConnection=true" --quiet --eval 'printjson(db.runCommand({ping:1}))' 

# Expected to fail because this lesson mapped host port 27018mongosh "mongodb://127.0.0.1:27017/?directConnection=true" --eval "db.runCommand({ping:1})"# Correct endpointmongosh "mongodb://127.0.0.1:27018/?directConnection=true" --quiet --eval 'printjson(db.adminCommand({hello:1}));printjson(db.adminCommand({getCmdLineOpts:1}));' 

The wrong-port attempt is intentionally non-destructive. Diagnose it from the port map; do not “repair” it by binding MongoDB to every interface or disabling security controls.

Cleanup

docker rm -f atlasmart-mongo-l4docker volume rm atlasmart-l4-data

7. Production judgment and next bridge

Production connection strings should represent topology and security intent, not only a reachable socket. Replica sets need discoverable member hostnames; sharded deployments normally connect through mongos; TLS names must validate; secrets need a secure delivery path; timeout and pool settings belong to a documented client policy. Server paths need durable storage and backup compatibility. Database and collection names need ownership and retention conventions.

Lesson 5 turns these pieces into one reproducible, authenticated AtlasMart lab with an explicit configuration file, persistent local volume, server log, an administrative user, a scoped application user, sample data, and a reset procedure.

Verification checklist

• You can map a URI host/port to the actual listener and process.
• You know the difference between mongodb:// and mongodb+srv://.
• You inspect parsed configuration and mounts rather than assuming dbPath.
• You can prove collection/database existence from metadata after a write.
• You can diagnose a wrong-port failure without weakening bind/security settings.

Authoritative references

• MongoDB release notes — Official source for the current stable server series and patch notes.
• MongoDB 8.3 release notes — Official 8.3 behavior, patch, compatibility, and security/reliability change log.
• mongosh release notes — Official shell release history; 2.10.0 was released 13 August 2026.
• Default MongoDB ports — Official port assignments for mongod, mongos, shard/config roles, and mongocryptd.
• Connection strings — Official standard/SRV formats and deployment selectors.
• Connection string formats — Official URI components, authSource behavior, percent encoding, and SRV/TLS notes.
• IP binding — Official localhost default and trusted-network guidance.
• Databases and collections — Official logical namespace behavior.