Secret Storage Issue

System info: https://0x0.st/H3V2.txt
(Linux 6.6.4-zen1-1-zen, i3-wm, lightdm)
Boot log: https://0x0.st/H3V9.txt
LightDM log: https://0x0.st/H3Vf.txt

I’ve been using tutanota-desktop-bin for a long time. Today when I start it, I am shown the message: “Could not access secret storage”. Followed by a link to this page.

I previously had a similar issue with Mailspring which was “fixed” with a workaround of modifying the /usr/share/applications/mailspring.desktop to have the following Exec line Exec=mailspring --password-store="gnome-libsecret" %U.

I’m assuming that a similar issue appearing again would mean there’s another larger issue here.

I installed seahorse to look for clues. I noticed that other applications such as Nextcloud are listed to be using a password or secret. Nextcloud seems to fail to store my encryption phrase but generally continues to function.

Installing KeePassXC, in the “Secret Service Integration”, it shows that another secret service is already running PID: 1002, Executable: /usr/share/bin/gnome-keyring-daemon

I’m not sure how or when these issues had started happening. Nextcloud has been unable to store it’s encryption phrase for as long as I can remember. I’ve tried looking into this issue a few times but to no avail.

More info/logs can be provided if needed. Thanks :slight_smile:

You probably just need a keyring tool. You can try this:

https://archlinux.org/packages/extra/x86_64/gnome-keyring/

You can check if it is already installed by doing

yay -Qi gnome-keyring
or
pacman -Qi gnome-keyring

Can confirm I have gnome-keyring installed already

Strange. Neither gnome-keyring nor libgnome-keyring require each other. Check if you also have libgnome-keyring. Do you have both installed?

On mine, it’s says libgnome-keyring is deprecated, so you may not actually need it. :thinking:

Although libgnome-keyring is deprecated (and superseded by libsecret), it may still be required by certain applications.

Have you already tried deleting your Tuta folder and starting from scratch? Can’t remember for sure, but I think that’s all I did the last time I had this issue. Was a Tuta from a previous install and the previous config/secret was the issue, I think.

libgnome-keyring is installed. I will uninstall it and see if anything of note changes, otherwise I’ll reinstall it since brave browser optionally requires it.

EDIT: No changes with or without libgnome-keyring.

I have tried deleting the ~/.config/tutanota-desktop/ folder and also removing anything to do with it from seahorse to no avail.

I believe the issue is not directly with Tutanota but it’s where I’ve noticed it today.

Try this (again, maybe):

  • Delete/uninstall Tuta
  • Delete .config/tutanota-desktop and the “integration” folder if you see it
  • Redownload/install Tuta and go through the setup
  • Make sure to select the “integration” checkbox

I ask you to do this because I just did it, ran into that same secret error message with the link to their page, but I was still able to log in.

PS: How do you access Tuta? AppImage, AUR, something else?
PS Two: I understand this may be a bigger thing for other apps, but one issue at a time. :sweat_smile:

I would usually use the tutanota-desktop-bin package from the AUR. I tried the flatpak version and it had the same outcome.

I have tried the steps above that version, also tried the flatpak version and just now tested with the tutanota-desktop package.

Unfortunately they all have the same output as in the initial post.

Willing to try one more? the AppImage? It’s what I use.

AppImage version has the same result too.

Okay, then.

@dalto Help! Pweez! :sweat_smile:

Might be related, on another system running Linux Mint with DWM, I get the same issues with secret storage unless I login to the DE which was installed by default (XFCE in this case).

It’s very likely that I’m not starting something which should be started in order for secret storage to work. If that’s the case, whatever solution is found here should be able to fix it on DWM on the other system, too.

Maybe it’s polkit? https://archlinux.org/packages/?q=polkit

There are multiple options.

I have polkit, polkit-kde-agent and polkit-qt5 installed. Does that seem correct?

polkit-qt5 is installed as a dependency of kauth5 which is a dependency of kconfigwidgets5 which is a dependency of a few other KDE apps, notably kwallet5.

It doesn’t really matter which one you have installed when it comes to tiling/dynamic WMs. All that matters is that one of them is set to autostart. You could actually just start one of them right now (from a terminal or dmenu), then try Tuta again.

It starts in my i3 config with the following line:
exec --no-startup-id /usr/lib/polkit-kde-authentication-agent-1

--- ~ ‹main* M?› » ps -e | grep polkit
769 ?        00:00:00 polkitd
23098 ?        00:00:00 polkit-kde-auth

It’s running but Tutanota still doesn’t recognise it. Nextcloud also doesn’t seem to.

EDIT: copied the wrong line, fixed

The line in my i3 is different for whatever reason. Try this:


exec --no-startup-id /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1 &

Again though, not saying it will work, but it doesn’t hurt to try it.

I’ll try adding the & to the end and if that doesn’t work, I’ll install the gnome version and try it instead

For the KDE version, try to go to that directory and see if it’s there.

May have to wait for one of the more experienced forum members to assist.

Not seeing anything in my startup list that would affect secrets, authentication etc. Only polkit.

Can confirm /usr/lib/polkit-kde-authentication-agent-1 exists.

Running pkexec seems to work fine also, if that’s related at all.

Checking the EndeavourOS i3wm setup, I don’t seem to be missing anything compared to the default:

--- Git/endeavouros-i3wm-setup ‹main› » search polkit
./etc/skel/.config/i3/config:370:#get auth work with polkit-gnome
./etc/skel/.config/i3/config:371:exec --no-startup-id /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1
--- Git/endeavouros-i3wm-setup ‹main› » search secret
./.github/workflows/gitlab.yml:17:            ${{ secrets.GITLAB_SYNC }}

search here is just an alias for grep -rn . -e

Maybe I’ve broke something system wide?