Plain Authentication not enabled: Komodo stack fails after auto-updating to new ferretdb 2.0 version #229

New Issue

2025-10-31T15:05:42-05:00

GiteaMirror commented

2025-10-31 15:05:42 -05:00

Originally created by @Elekam on GitHub (Feb 26, 2025).

Hello,

I noticed my komodo didnt work as expected after I updated all my stacks.
The reason is that komodos ferretdb updated to version 2.0, which handles authentication differently.

If you use the current recommended docker compose for the komodo postgres-backend, your ferretdb image does not have a version tag, and therefore defaults to the latest tag. This is of course not a good practice because it creates issues like this. I probably overlooked this when I setup komodo.

I gave my ferretdb the 1 tag like this: image: ghcr.io/ferretdb/ferretdb:1 and everything works again.
While I was at it I also pinned the postgres backend to the current major version 17.

Two issues:

The documentation should be updated to use version tags for all container images in its recommended docker composes to prevent anything like this happening. At least a major version like 1.
Komodo should migrate/update to the new authentication system in the docker compose. Not sure how complicated that is currently. Would need to look further into it if I find the time. For now I will stay at version 1.

Originally created by @Elekam on GitHub (Feb 26, 2025). Hello, I noticed my komodo didnt work as expected after I updated all my stacks. The reason is that komodos ferretdb updated to version 2.0, which handles authentication differently. If you use the current [recommended docker compose](https://komo.do/docs/setup/postgres) for the komodo postgres-backend, your ferretdb image does not have a version tag, and therefore defaults to the latest tag. This is of course not a good practice because it creates issues like this. I probably overlooked this when I setup komodo. I gave my ferretdb the 1 tag like this: `image: ghcr.io/ferretdb/ferretdb:1 ` and everything works again. While I was at it I also pinned the postgres backend to the current major version 17. Two issues: - The documentation should be updated to use version tags for all container images in its recommended docker composes to prevent anything like this happening. At least a major version like 1. - Komodo should migrate/update to the new authentication system in the docker compose. Not sure how complicated that is currently. Would need to look further into it if I find the time. For now I will stay at version 1.

GiteaMirror added the seen 👀 label 2025-10-31 15:05:42 -05:00

GiteaMirror closed this issue

2025-10-31 15:05:42 -05:00

GiteaMirror commented

2025-10-31 15:05:43 -05:00

@ValgulNecron commented on GitHub (Feb 26, 2025):

hi thanks was wondering why everything broke

@ValgulNecron commented on GitHub (Feb 26, 2025): hi thanks was wondering why everything broke

GiteaMirror commented

2025-10-31 15:05:43 -05:00

@Hanibachi commented on GitHub (Feb 26, 2025):

i have been trying to deploy it and its not working i wonder if this is related , cuz i keep seeing this in the logs :

komodo       | thread 'tokio-runtime-worker' panicked at bin/core/src/state.rs:46:6:
komodo       | called `Result::unwrap()` on an `Err` value: failed to initialize database client
komodo       | 
komodo       | Caused by:
komodo       |     0: failed to init mongo with given args
komodo       |     1: Kind: An invalid argument was provided: No username provided for PLAIN authentication, labels: {}
komodo       | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
komodo       | Error: task 5 panicked with message "called `Result::unwrap()` on an `Err` value: failed to initialize database client\n\nCaused by:\n    0: failed to init mongo with given args\n    1: Kind: An invalid argument was provided: No username provided for PLAIN authentication, labels: {}"
komodo exited with code 1

@Hanibachi commented on GitHub (Feb 26, 2025): i have been trying to deploy it and its not working i wonder if this is related , cuz i keep seeing this in the logs : ``` komodo | thread 'tokio-runtime-worker' panicked at bin/core/src/state.rs:46:6: komodo | called `Result::unwrap()` on an `Err` value: failed to initialize database client komodo | komodo | Caused by: komodo | 0: failed to init mongo with given args komodo | 1: Kind: An invalid argument was provided: No username provided for PLAIN authentication, labels: {} komodo | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace komodo | Error: task 5 panicked with message "called `Result::unwrap()` on an `Err` value: failed to initialize database client\n\nCaused by:\n 0: failed to init mongo with given args\n 1: Kind: An invalid argument was provided: No username provided for PLAIN authentication, labels: {}" komodo exited with code 1 ```

GiteaMirror commented

2025-10-31 15:05:43 -05:00

@mbecker20 commented on GitHub (Feb 26, 2025):

Update the compose file to use ghcr.io/ferretdb/ferretdb:1 as the ferretdb image.
You have to use the :1 tag explicitly now. Komodo is still on ferretdb v1, as their recent v2 release has a lot of changes, isn't backward compatible (requires a migration process), and does not currently support ARM hardware.
I've already updated the official compose documentation to include this change

@mbecker20 commented on GitHub (Feb 26, 2025): Update the compose file to use ghcr.io/ferretdb/ferretdb:1 as the ferretdb image. You have to use the :1 tag explicitly now. Komodo is still on ferretdb v1, as their recent [v2 release](https://blog.ferretdb.io/ferretdb-releases-v2-faster-more-compatible-mongodb-alternative/) has a lot of changes, isn't backward compatible (requires a migration process), and does not currently support ARM hardware. I've already updated the official compose documentation to include this change

GiteaMirror commented

2025-10-31 15:05:43 -05:00

@Elekam commented on GitHub (Feb 27, 2025):

@mbecker20 Should I leave this issue open as a reminder to switch to ferretdbv2 in the future or close it for now? I assume you will wait until it has at least ARM support?

@Elekam commented on GitHub (Feb 27, 2025): @mbecker20 Should I leave this issue open as a reminder to switch to ferretdbv2 in the future or close it for now? I assume you will wait until it has at least ARM support?

GiteaMirror commented

2025-10-31 15:05:43 -05:00

@AlekSi commented on GitHub (Feb 27, 2025):

Hey, folks. FerretDB maintainer there. Sorry that we broke things for you. Aside from https://github.com/FerretDB/FerretDB/issues/4726 (please 👍 it), what else blocks you from migrating to v2?

@AlekSi commented on GitHub (Feb 27, 2025): Hey, folks. FerretDB maintainer there. Sorry that we broke things for you. Aside from https://github.com/FerretDB/FerretDB/issues/4726 (please 👍 it), what else blocks you from migrating to v2?

GiteaMirror commented

2025-10-31 15:05:44 -05:00

@mbecker20 commented on GitHub (Feb 28, 2025):

Hey @AlekSi, apart from ARM support, the database cannot be upgraded in place from 1.x to 2.x. The reasons for this are clear to me, but to the users who aren't watching this closely, they may not be. A clearly documented migration procedure from 1.x to 2.x would be greatly appreciated for these existing users, then I can refer the users on v1 to the procedure in a PSA released alongside the updated Komodo documentation for FerretDB v2.

@mbecker20 commented on GitHub (Feb 28, 2025): Hey @AlekSi, apart from ARM support, the database cannot be upgraded in place from 1.x to 2.x. The reasons for this are clear to me, but to the users who aren't watching this closely, they may not be. A clearly documented migration procedure from 1.x to 2.x would be greatly appreciated for these existing users, then I can refer the users on v1 to the procedure in a PSA released alongside the updated Komodo documentation for FerretDB v2.

GiteaMirror commented

2025-10-31 15:05:44 -05:00

@AlekSi commented on GitHub (Feb 28, 2025):

Thank you. You can track it in https://github.com/FerretDB/FerretDB/issues/4789.

@AlekSi commented on GitHub (Feb 28, 2025): Thank you. You can track it in https://github.com/FerretDB/FerretDB/issues/4789.

GiteaMirror commented

2025-10-31 15:05:45 -05:00

@AlanMW commented on GitHub (Mar 28, 2025):

i have been trying to deploy it and its not working i wonder if this is related , cuz i keep seeing this in the logs :

komodo       | thread 'tokio-runtime-worker' panicked at bin/core/src/state.rs:46:6:
komodo       | called `Result::unwrap()` on an `Err` value: failed to initialize database client
komodo       | 
komodo       | Caused by:
komodo       |     0: failed to init mongo with given args
komodo       |     1: Kind: An invalid argument was provided: No username provided for PLAIN authentication, labels: {}
komodo       | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
komodo       | Error: task 5 panicked with message "called `Result::unwrap()` on an `Err` value: failed to initialize database client\n\nCaused by:\n    0: failed to init mongo with given args\n    1: Kind: An invalid argument was provided: No username provided for PLAIN authentication, labels: {}"
komodo exited with code 1

@Hanibachi No, I had the same thing, it is unrelated. Turns out docker compose for whatever reason cant't parse my compose.env file. You can verify if that is the issue by running docker compose config and checking if the variables are blank for where your username and password are added. I fixed it by changing my env file name to just being .env and setting my compose file to use .env, env_file: .env

@AlanMW commented on GitHub (Mar 28, 2025): > i have been trying to deploy it and its not working i wonder if this is related , cuz i keep seeing this in the logs : > > ``` > komodo | thread 'tokio-runtime-worker' panicked at bin/core/src/state.rs:46:6: > komodo | called `Result::unwrap()` on an `Err` value: failed to initialize database client > komodo | > komodo | Caused by: > komodo | 0: failed to init mongo with given args > komodo | 1: Kind: An invalid argument was provided: No username provided for PLAIN authentication, labels: {} > komodo | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace > komodo | Error: task 5 panicked with message "called `Result::unwrap()` on an `Err` value: failed to initialize database client\n\nCaused by:\n 0: failed to init mongo with given args\n 1: Kind: An invalid argument was provided: No username provided for PLAIN authentication, labels: {}" > komodo exited with code 1 > ``` @Hanibachi No, I had the same thing, it is unrelated. Turns out docker compose for whatever reason cant't parse my compose.env file. You can verify if that is the issue by running `docker compose config` and checking if the variables are blank for where your username and password are added. I fixed it by changing my env file name to just being .env and setting my compose file to use .env, `env_file: .env`

GiteaMirror commented

2025-10-31 15:05:45 -05:00

@mbecker20 commented on GitHub (Aug 27, 2025):

Think we are all good here

@mbecker20 commented on GitHub (Aug 27, 2025): Think we are all good here