UnhandledPromiseRejectionWarning: MongoError: command listDatabases requires authentication

[infoShare]

After last updates without any changes new issue occurred on mongo express (using docker compose):

Configuration:

    ports:
      - "8081:8081"
    environment:
      ME_CONFIG_MONGODB_ADMINUSERNAME: root
      ME_CONFIG_MONGODB_ADMINPASSWORD: XXX
      ME_CONFIG_BASICAUTH_USERNAME: root
      ME_CONFIG_BASICAUTH_PASSWORD: XXX

And error:

(node:6) [MONGODB DRIVER] Warning: Current Server Discovery and Monitoring engine is deprecated, and will be removed in a future version. To use the new Server Discover and Monitoring engine, pass option { useUnifiedTopology: true } to the MongoClient constructor.
(node:6) UnhandledPromiseRejectionWarning: MongoError: command listDatabases requires authentication
    at Connection.<anonymous> (/node_modules/mongodb/lib/core/connection/pool.js:451:61)
    at Connection.emit (events.js:314:20)
    at processMessage (/node_modules/mongodb/lib/core/connection/connection.js:451:10)
    at Socket.<anonymous> (/node_modules/mongodb/lib/core/connection/connection.js:620:15)
    at Socket.emit (events.js:314:20)
    at addChunk (_stream_readable.js:297:12)
    at readableAddChunk (_stream_readable.js:272:9)
    at Socket.Readable.push (_stream_readable.js:213:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:188:23)
(node:6) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:6) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

[weibell]

I am experiencing the same issue. As a temporary workaround, I will be using the previous version mongo-express:0.54 instead of the :latest image.

[emajeru]

I had the same issue at first and saw the the default environment variables changed with the new release. Instead of passing the mongo connection credentials as individual variables, I passed them in the connection string in order to get them working.

Configuration:

environment:
    ME_CONFIG_MONGODB_URL:  mongodb://root:xxx@mongo:27017
    ME_CONFIG_BASICAUTH_USERNAME: root
    ME_CONFIG_BASICAUTH_PASSWORD: XXX

[gBusato]

As said previously, this is an example of working configuration :

version: '3.1'

services:

  mongo:
    image: mongo
    restart: always
    environment:
      MONGO_INITDB_ROOT_USERNAME: root
      MONGO_INITDB_ROOT_PASSWORD: example

  mongo-express:
    image: mongo-express
    restart: always
    ports:
      - 8081:8081
    environment:
      ME_CONFIG_MONGODB_URL: "mongodb://root:example@mongo:27017/"
      ME_CONFIG_MONGODB_ADMINUSERNAME: root
      ME_CONFIG_MONGODB_ADMINPASSWORD: example

[rpsirois]

Thanks @weibell downgrading worked for usage with secrets since I can't use the url method.

[chahinebh]

I use version mongo-express:0.54 instead of the :latest image.

[cgrio]

I use version mongo-express:0.54 instead of the :latest image.

It`s works for me.

[mholimncube]

@cgrio I used that 0.54 tag and it did not work for me, actually tried all the tags for the official image and they all give the same error. Anyone has an Idea how to resolve this issue?

[Yuri-Lima]

official image an

I have been using this:
version: '3.7'

services:
  mongo:
    image: mongo
    restart: always
    command: mongod --auth
    environment:
      #MONGO_INITDB_DATABASE: "{{DBNAME}}"
      MONGO_INITDB_ROOT_USERNAME: {{USER}}
      MONGO_INITDB_ROOT_PASSWORD: {{PASSWORD}}
    ports:
      - "27017:27017"
    volumes:
      - mongo_db:/data/db
  mongo-express:
    image: mongo-express
    restart: always
    ports:
      - 8081:8081
    environment:
      ME_CONFIG_MONGODB_ADMINUSERNAME: {{USER}}
      ME_CONFIG_MONGODB_ADMINPASSWORD: {{PASSWORD}}
      #ME_CONFIG_MONGODB_DATABASE: "{{DBNAME}}"     
      ME_CONFIG_MONGODB_URL: "mongodb://{{USER}}:{{PASSWORD}}@mongo:27017/"      
volumes:
  mongo_db: {}
networks:
  default:
    external: true
    name: portainer

[pablonap]

It worked for me only when I added depends_on as follows:

version: '3'
services:
  mongodb:
    image: mongo
    ports:
      - 27017:27017
    environment:
      - MONGO_INITDB_ROOT_USERNAME=admin
      - MONGO_INITDB_ROOT_PASSWORD=password
  mongo-express:
    image: mongo-express
    ports:
      - 8081:8081
    depends_on:
      - "mongodb"
    environment:
      - ME_CONFIG_MONGODB_ADMINUSERNAME=admin
      - ME_CONFIG_MONGODB_ADMINPASSWORD=password
      - ME_CONFIG_MONGODB_SERVER=mongodb

[saurabhsri108]

Doesn't work in March. 2023

version: '3.1'
services:
  mongodb:
    image: mongo
    restart: always
    ports:
      - 27017:27017
    environment:
      - MONGO_INITDB_ROOT_USERNAME=admin
      - MONGO_INITDB_ROOT_PASSWORD=password
  mongo-express:
    image: mongo-express
    restart: always
    ports:
      - 8081:8081
    depends_on:
      - "mongodb"
    environment:
      - ME_CONFIG_MONGODB_ADMINUSERNAME=admin
      - ME_CONFIG_MONGODB_ADMINPASSWORD=password
      - ME_CONFIG_MONGODB_SERVER=mongodb

[turbo5]

I mean, this seems to be a pretty major bug and/or big oversight, since one of the most basic thing is to be able to wait for a service to start and only then start the one depending on it right? I just started using Docker and this thing actually worked in an earlier version from what I saw, or at least mongo-express tried to reconnect by itself until mongo has finished initializing.
How can this even go wrong and not to be solved for this long? This kind of questions the whole existence of docker-compose if it doesn't work reliably.
Anyone had some success with the new 'condition' attribute?

edit:
adding restart: unless-stopped to the mongo-express service seems to do the trick (for now), but I still don't know if this solves the core issue or just somehow works until the next minor version bump.