Storage issue with connections on ubuntu/linux (credential store)

[Tofandel]

Mongodbcompass: 1.20.5
Kubuntu: 19.04

None of my connections/settings are stored, when I restart the app my favorite or recent connections are lost

I'm getting this error:

Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files
(node:10188) UnhandledPromiseRejectionWarning: ReferenceError: error is not defined
    at /usr/share/mongodb-compass-community/resources/app.asar/node_modules/storage-mixin/lib/backends/secure-main.js:87:42

WIth a bit of research I found a similar issue Foundry376/Mailspring#681

sudo apt install gnome-keyring solved the issue but adding it as a dependency would be a good idea

[molten-firescar96]

The issue for me was related to mongo-compass being unable to access https://en.wikipedia.org/wiki/GNOME_Keyring.

I tried a couple solutions online such as https://bbs.archlinux.org/viewtopic.php?id=224652 to no avail. I read that most login managers (lightdm, ssdm, gdm, etc.) will unlock it at the time of login -> I now use lightdm instead of logging into my computer from the terminal with a call to startx and it's working okay.

There is still a wierd glitch where the first time mongo-compass is opened after login it immediately exits and subsequent versions work fine.

[myknbani]

Same experience here. MongoDB Compass exits just one time, perhaps trying to open Gnome Keyring. Subsequent opens work fine.

[niconiconiconiconiconi]

Getting this issue with:

• mongodb-compass 1.33.1-1
• endeavourOS

installing gnome-keyring also solved it for me

[SiNONiMiTY]

This must be documented on the Linux Installation section

[pedrokuper]

Getting this issue with:

• mongodb-compass 1.33.1-1
• endeavourOS

installing gnome-keyring also solved it for me

i have gnome-keyring installed but the problem persist. Did you do anything else than installing it?

[alenakhineika]

Hey @pedrokuper, which OS do you have? Is it also endeavourOS?

[dladeira]

I've got the same problem on KDE with Debian 12, already have gnome-keyring installed as well.

Same experience here. MongoDB Compass exits just one time, perhaps trying to open Gnome Keyring. Subsequent opens work fine.

Exact same thing happens to me

[zneix]

Could this please be looked into? As much as I hate to be this person "bumping up" the issues, I do want to report I have been facing the same issue of credentials not being read/written from/into the keyring for at least few months now - I am pretty sure this wasn't always the case (I do have some passwords that were used by mongodb-compass saved in it) yet I haven't changed anything on my side with my setup or installed packages.
I am on Arch Linux 6.8.9.arch1-2 with mongodb-compass 1.43.0-1 package installed from the AUR.
I do use a non-standard keyring implementation (pass-secrets-git), however I have verified with other applications that make use of keyring that it fully re-implements regular secret store and its interfaces.
If there is anything I could do to help with resolving this issue, I'd be happy to help.

[mcasimir]

We are working on adding a message to signal if the secret storage can be accessed or not. We will consider updating the requirements for the linux installation as well.

Did you do anything else than installing it?

You can verify if is running:

ps aux | grep gnome-keyring-daemon

If is not running, you can try to start it manually once:

/usr/bin/gnome-keyring-daemon --start --components=secrets,ssh

and try again to see if compass would allow storing secrets. I'm not sure if more steps are necessary to make sure that the daemon can run properly.

If that would work, you may want to create a service to run the daemon at start up.

[mcasimir]

@zneix newer versions of Compass use https://www.electronjs.org/docs/latest/api/safe-storage to access the keyring. We never tested a backend different from gnome-keyring, but I would assume that any storage that announces as a valid backend would be picked up.

A minimal test script:

// testsafestorage.js
const { app, safeStorage } = require('electron');
const assert = require('assert');

app.on('ready', () => {
  if (!safeStorage.isEncryptionAvailable()) {
    console.error('Safe storage is not available on this system.');
    app.quit();
    return;
  }

  if (safeStorage.getSelectedStorageBackend) {
    console.log('backend:', safeStorage.getSelectedStorageBackend());
  }

  const secret = 'MySecret';
  const encrypted = safeStorage.encryptString(secret);
  const decrypted = safeStorage.decryptString(encrypted);

  assert.notEqual(secret.toString('base64'), encrypted.toString('base64'));
  assert.equal(secret, decrypted);

  console.log('OK');
  app.quit();
});

npx electron testsafestorage.js

[zneix]

Thank you for a very straightforward reply!
I've copied & saved the script you've provided, ran it and it did print Safe storage is not available on this system. when used with my custom backend up and running.

After that, just to eliminate possibility of there being a potential issue with the custom backend I use, I've decided to install gnome-keyring package (which in result also was conflicting with custom backend, so I've removed it and made sure to disable & stop the systemd unit for it) - sadly that also yielded the same result:

I'm not sure if this means that I'm either missing some system library (assuming issue would be on my environment's side) or have something related to the keyring misconfigured.
I can see safe-storage API's documentation mentioning necessity of a "secret key" being available to make the function that fails for me return true, but I don't have a clue what to do with that further nor what does "secret key" refer to specifically.
Let me know if there's anything more I can do. Cheers.

[zneix]

Just now, I've tried to comment-out the first if statement and see what happens with the code;
I did get a popup with javascript exception, which was expected, but the script continued to run and a message backend: basic_text was printed (nothing past that though, since I expected assert statements to also fail).

The reason why I mention that is because description for basic_text value mentions following: When the desktop environment is not recognised [...] and maybe it will be helpful to note that I do not have a desktop environment installed, but rather a window manager i3, which might behave differently and be a related cause of the safe storage not being available.

[zneix]

Another thing that I found after a bit of poking around is that when I start Compass with mongodb-compass --ignore-additional-command-line-flags --password-store="gnome-libsecret" the password is picked up from and saved to the keyring just fine - even with my backend.
As well as running your script with npx electron --password-store="gnome-libsecret" testsafestorage.js makes it work just fine, printing backend: gnome_libsecret OK ('OK' is on a new line of course) then exitting gracefully.

Note that for password-store flag, using any value other than "gnome-libsecret" (from the ones listed in documentation at https://www.electronjs.org/docs/latest/api/safe-storage#safestoragegetselectedstoragebackend-linux) does not yield the success.
I'm sorry for a chaos with replies, but I hope that the extra context might help to narrow down the issue.

[zneix]

Even more research has lead me onto the very similar issues with vscode [ 1 ], which seems like it's an issue with electron itself being unable to detect the desktop environment, which turns out to be critical towards being able to determine whether the electron application should look for gnome keyring / kwallet / etc.
I can verify that because attempting to run the script with the XDG_CURRENT_DESKTOP environment variable being set to GNOME, which seems to be how Electron determines the environment, makes the script work OK, as well as the MongoDB Compass itself.

[ 1 ]: microsoft/vscode#187338 microsoft/vscode#185212

[HermesDE]

Hello, im on Fedora 40 Workstation and have the same issue. I have gnome-keyring installed and running but its not working.

[astanwar99]

Facing similar issue here:

➜  ~ uname -a
Linux astanwar99 6.9.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 28 Jun 2024 04:32:50 +0000 x86_64 GNU/Linux
➜  ~ echo $XDG_CURRENT_DESKTOP
i3
➜  ~ mongodb-compass --version                                                        
MongoDB Compass 1.43.4
➜  ~ ps aux | grep gnome-keyring-daemon
astanwa+    2121  0.0  0.0 311880 10876 ?        SLsl 09:59   0:00 /usr/bin/gnome-keyring-daemon --foreground --components=pkcs11,secrets --control-directory=/run/user/1000/keyring

This works though:

mongodb-compass --ignore-additional-command-line-flags --password-store="gnome-libsecret"

Thanks @zneix. Basically, you're saying that fix will come from electron right? For time being, can we set these flags in launch options or any config file for compass?

[gribnoysup]

Hey everybody, we're trying to figure out if we can apply this option automatically in some cases, but trying to do a solid reproduction takes awhile, so bear with us please while we're doing this. For the time being, making sure that you have gnome-keyring installed and passing --ignore-additional-command-line-flags --password-store="gnome-libsecret" option explicitly should help you work around the issue. @zneix thanks a ton for debugging this and finding the root cause!

[voglster]

I run debian stable with i3wm pretty much stock and was running into this issue. I can confirm the running with the additional flag fixes it. If you need help with the repro let me know but thats a very simple vm to create that can reproduce this.

[olealgoritme]

--password-store="gnome-libsecret" adding this fixed the issue for me. Thanks

[shanujha]

I was trying to run MongoDB Compass using the desktop file in /usr/share/applications with additional command-line flags. I wanted to use the --ignore-additional-command-line-flags --password-store="gnome-libsecret" flags to ensure Compass would correctly access the credential store.

In the original desktop file, the Exec line included an additional %U at the end. However, no matter where I placed this %U in the command, MongoDB Compass wouldn’t accept the --password-store flag, which meant it couldn’t access the credential store.

As a workaround, I removed the %U from the Exec line and added my desired flags. Now, Compass launches correctly from the desktop entry with access to the credential store.

If anyone has experience with this and knows whether removing %U could compromise security or functionality, I’d appreciate any insights.

[gxanshu]

if anyone is on kde then make sure to turn on KWallet. it solves for me

[m34nbunny]

Another thing that I found after a bit of poking around is that when I start Compass with mongodb-compass --ignore-additional-command-line-flags --password-store="gnome-libsecret" the password is picked up from and saved to the keyring just fine - even with my backend. As well as running your script with npx electron --password-store="gnome-libsecret" testsafestorage.js makes it work just fine, printing backend: gnome_libsecret OK ('OK' is on a new line of course) then exitting gracefully.

Note that for password-store flag, using any value other than "gnome-libsecret" (from the ones listed in documentation at https://www.electronjs.org/docs/latest/api/safe-storage#safestoragegetselectedstoragebackend-linux) does not yield the success. I'm sorry for a chaos with replies, but I hope that the extra context might help to narrow down the issue.

I am on ArchLinux, i3, and running with this command worked for me. I've been banging my head against the wall trying to fix this for days now...