I had the same issue, but it worked fine if you installed version 2024.3.2 from the .deb file.

Same issue, Ubuntu 22.04.4 LTS.

Also, when I try to save a new entry, I get an error "Failed to decode access token; JWT must have 3 parts".

Echo-ing everyone else - 2024.3.2 snap install presented issues in multiple ways:

• saved TOTP tokens no longer displayed generated codes (said "Premium plan required")
• attempts to sync or add items resulted in the "JWT must have 3 parts" banner error
• a complete log-out and then log-in resulted in a spinner and no items appearing

Reverting to 2024.3.0 restored functionality

Same issue Ubuntu 22.04.4 LTS

I use snap and reverting versions worked (tip by @justin-yan ). Full command: sudo snap revert bitwarden

Hi everyone, thank you for the reports! We moved to storing our tokens in secure storage with this release, but unfortunately snap packages are sandboxed and we can't automatically enable access to the password-manager-service permission. If you're running into this issue there are a couple fixes:

1. Ubuntu Software > Installed > Bitwarden > Permissions - turn on "Read, add, change or remove saved passwords"
2. Run the following: sudo snap connect bitwarden:password-manager-service

Please be sure to log out and back in after enabling this permission. If you encounter any issues please feel free to reach out, thanks!

Hi everyone, thank you for the reports! We moved to storing our tokens in secure storage with this release, but unfortunately snap packages are sandboxed and we can't automatically enable access to the password-manager-service permission. If you're running into this issue there are a couple fixes:

1. Ubuntu Software > Installed > Bitwarden > Permissions - turn on "Read, add, change or remove saved passwords"
2. Run the following: sudo snap connect bitwarden:password-manager-service

Please be sure to log out and back in after enabling this permission. If you encounter any issues please feel free to reach out, thanks!

Same problem on Ubuntu 23.10 Desktop and Bitwarden installed via snap package (current Bitwarden version: 2024.4.0).

Versione 2024.4.0
Shell 28.2.8
Renderer 120.0.6099.291
Node 18.18.2
Architecture x64

Unfortunately the described solution doesn't seem to work...

Hi everyone, thank you for the reports! We moved to storing our tokens in secure storage with this release, but unfortunately snap packages are sandboxed and we can't automatically enable access to the password-manager-service permission. If you're running into this issue there are a couple fixes:

1. Ubuntu Software > Installed > Bitwarden > Permissions - turn on "Read, add, change or remove saved passwords"
2. Run the following: sudo snap connect bitwarden:password-manager-service

Please be sure to log out and back in after enabling this permission. If you encounter any issues please feel free to reach out, thanks!

Same problem on Ubuntu 23.10 Desktop and Bitwarden installed via snap package (current Bitwarden version: 2024.4.0).

Versione 2024.4.0
Shell 28.2.8
Renderer 120.0.6099.291
Node 18.18.2
Architecture x64

Unfortunately the described solution doesn't seem to work...

Try logging out of your account (File > Esci > tuo account) and then logging back in. It worked for me

I think i have the same issue, i installed "bitwarden" on ubuntu via snap. I have version stable 2024.4.0

Error:
0:12:04.375 › Error: Failed to decode access token: JWT must have 3 parts (node:27511) UnhandledPromiseRejectionWarning: TypeError: Cannot read properties of undefined (reading 'setContextMenu') at TrayMain.updateContextMenu (/snap/bitwarden/108/resources/app.asar/main.js:88410:23) at MessagingMain.updateTrayMenu (/snap/bitwarden/108/resources/app.asar/main.js:87873:28) at MessagingMain.onMessage (/snap/bitwarden/108/resources/app.asar/main.js:87795:22) at MessagingMain.<anonymous> (/snap/bitwarden/108/resources/app.asar/main.js:87783:155) at Generator.next (<anonymous>) at /snap/bitwarden/108/resources/app.asar/main.js:87760:71 at new Promise (<anonymous>) at messaging_main_awaiter (/snap/bitwarden/108/resources/app.asar/main.js:87756:12) at IpcMainImpl.<anonymous> (/snap/bitwarden/108/resources/app.asar/main.js:87783:83) at IpcMainImpl.emit (node:events:517:28) (node:27511) 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: 2) ** Message: 20:12:11.557: Remote error from secret service: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.406" (uid=1000 pid=27511 comm="/snap/bitwarden/108/bitwarden --no-sandbox" label="snap.bitwarden.bitwarden (enforce)") interface="org.freedesktop.Secret.Service" member="OpenSession" error name="(unset)" requested_reply="0" destination=":1.7" (uid=1000 pid=2942 comm="/usr/bin/gnome-keyring-daemon --foreground --compo" label="unconfined")

My bug report was marked as closed and pointed towards here as the same issue. But I am not on a Linux platform so the fix doesn't apply to me, I am on Windows. Newest version 2024.4.0 does not resolve the issue. Still have to downgrade to below 2024.3.2 to restore functionality.

I'm still experiencing this issue with the Arch Linux package. I had to rollback to 2024.3.0 and remove my ~/.config/Bitwarden directory to get it to work.

Bitwarden is not a snap package on Arch Linux, so the snap connect ... workaround is not applicable.

Edit:
I wanted to add that I managed to resolve my immediate issue by enabling kwallet, which I normally have disabled. So it seems that bitwarden-desktop now depends on a desktop environment's own password manager (i.e. kwallet, gnome-keyring, ...) This seems... illogical? It also means you can't even open your vault if you're running a more barebones window manager, not everyone chooses to run a full DE ...

Hi everyone, thank you for the reports! We moved to storing our tokens in secure storage with this release, but unfortunately snap packages are sandboxed and we can't automatically enable access to the password-manager-service permission. If you're running into this issue there are a couple fixes:

1. Ubuntu Software > Installed > Bitwarden > Permissions - turn on "Read, add, change or remove saved passwords"
2. Run the following: sudo snap connect bitwarden:password-manager-service

Please be sure to log out and back in after enabling this permission. If you encounter any issues please feel free to reach out, thanks!

Same problem on Ubuntu 23.10 Desktop and Bitwarden installed via snap package (current Bitwarden version: 2024.4.0).

Versione 2024.4.0
Shell 28.2.8
Renderer 120.0.6099.291
Node 18.18.2
Architecture x64

Unfortunately the described solution doesn't seem to work...

Try logging out of your account (File > Esci > tuo account) and then logging back in. It worked for me

This didn't work for me, even after a full reboot I get the same error.
In the end I uninstalled the snap and reinstalled from the .deb file
I appreciate this means no automatic updates, but for now I'll take that over an update that might break things with no notice.
System is: Ubuntu 23.10 64 bit GNOME 45.2, Wayland WS

I too am seeing this issue and not using snap (I think when I first started w/Birwarden, snap wasn't available):
Ubuntu 23.10 KDE
Bitwarden-2024.4.1-x86_64.AppImage

Hey ya'll, this turned out to be a little bigger than we initially thought. We're working on a fix in #8776 that should resolve the token errors being reported.

If anyone has the time to test #8776 on their system, we would also appreciate the help. We're looking to discover potential issues early on. Thanks!

Worth a note @jlf0dev - I have a secret service installed (kwallet) with the same issue. But it seems the problem isn't that bitwarden can't find it. The problem seems to be it fails to open the wallet!
When I reboot, sync fails, as to be expected. However, if I open the wallet manually via kwalletmanager, all sync operations start to work!

Sick and tired with this rubbish! Can`t they fix it for once and forever.

I confirm problem is fixed on bitwarden-2024.5.0-1 on arch :)

Still does not work in openSUSE Tumbleweed using the latest appimage 2024.5. It does not sync. Back to the build mentioned above, at least it doesn't auto update.

The new version solved it for me on Ubuntu 24.04 and Ubuntu 23.10 using snap, needed to give the package additional permissions mentioned earlier in #8651 (comment), log out and log back in. Just locking the vault or restarting the application is not enough for the fix to take effect.

I can comfirm the problem has been solved for me on openSUSE Tumbleweed with the recent update of "org.freedesktop..." related packages (version 23.08).
It wasn't related specificaly to BitWarden, the same problem was happening for me on StandardNote flatpak package.

For folks with this problem. Be aware that the bitwarden writes in syslog that it doesn't have permissions. Mentioning because after a while my syslog was 30GB in size. 👍

For folks with this problem. Be aware that the bitwarden writes in syslog that it doesn't have permissions. Mentioning because after a while my syslog was 30GB in size. 👍

more and more i get a feeling that this isn't quality software, but hipster software.

on fedora it is journalctl btw for anyone who is searching for the syslog file.

@solumath can you expand on this a bit, perhaps including an error message that you're seeing, as well as the distribution method that you're using for the application (Snap, etc.)?

We want to make sure to address this issue if possible.

@solumath can you expand on this a bit, perhaps including an error message that you're seeing, as well as the distribution method that you're using for the application (Snap, etc.)?

We want to make sure to address this issue if possible.

Hey, thank you for reaching out. I didn't note the error. I vaguely remember it read out bitwarden ... permission denied [13].... So don't think that will help, sorry. I tried to replicate but I upgraded to 2024.5.0 and can't reproduce it so It seems it was fixed in the meantime.

I'm on ubuntu 24.04, used snap manager. Version before was 2024.4.1

Hello,

As this thread has a lot of history, we felt it would be good to summarize the current status of the issue and the options available.

Summary of current behavior

The current version (2024.5.0) uses libsecret to communicate over D-BUS with the org.freedesktop.secrets Secret Service implementation (e.g. gnome-keyring) in order to store persistent authentication tokens if your vault timeout action is "Lock". If there is no such service configured (or the application has issues communicating with the service), the current version does not have any built-in fallback to disk storage for the tokens, which is what is causing the errors experienced in this ticket. The mechanism for fallback will be introduced in the next release of our desktop application, as we are doing extensive internal testing to make sure that we do not introduce any regressions in behavior across all of the affected OSes.

As there are a lot of different parties involved in that communication path, we have seen some issues arise and raised on this thread. We'd like to highlight them below and make sure that the solutions are documented. We will also be updating our Help Center documentation to reflect this in more detail as we release the next update.

🗒️ Issue 1: The application doesn't have permission to communicate over D-BUS to the Secret Service

For our Snap sandboxed deployments, it is necessary to grant the application permission to access the service via D-BUS. This can be done with sudo snap connect bitwarden:password-manager-service.

🗒️ Issue 2: There is no Secret Service configured

As some have noted, configuring gnome-keyring will satisfy this requirement. It was an oversight on our part to not provide documentation for those users who would not have such a provider configured by default.

For those using kwallet, additional configuration may be required, as @Caligatio called out here:

[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/kwalletd6

In addition, there is a recent bug reported with Flatpak and kwallet that would potentially affect Flatpak users who are attempting to use kwallet as their secret provider.

If you do not have a Secret Service configured, and prefer not to do so, this build is available to install. This is the build currently under test for our next release. This is a development build and we recommend backing up your vault before use.

Once again, we thank you for your patience as we work through this issue. If there are any problems that do not conform to these assumptions, please raise them so that we can make sure that we take them into consideration.

OS: Arch Linux x86_64
Kernel: 6.9.2-arch1-1
Version 2024.5.0
Shell 28.3.3
Renderer 120.0.6099.291
Node 18.18.2
Architecture x64

1. Tried to log in using Yubikey as 2FA.
2. Selected "Remember me" on the Yubikey step; after touching the Yubikey there comes the message "Failed to decode access token; JWT must have 3 parts".

Alternatively, when "Remember me" is not selected, it "logs in", but only to show a spinning wheel and no vault items whatsoever.

Good morning,
I'm running bitwarden snap on Ubuntu 22.04. After doing all the manipulations -> still doesn't work.
Remove /home/snap/bitwarden folder.
Re-launch bitwarden -> OK.

Good morning, I'm running bitwarden snap on Ubuntu 22.04. After doing all the manipulations -> still doesn't work. Remove /home/snap/bitwarden folder. Re-launch bitwarden -> OK.

Same situation, tried all suggestions, but this one worked for me.

For me, it works:

1. log out
2. uncheck remember email
3. log in
4. log out
5. check remember email

I'm still experiencing this issue with the Arch Linux package. I had to rollback to 2024.3.0 and remove my ~/.config/Bitwarden directory to get it to work.

Thank you all for the incredible detail on this issue.

I am running Debian 12 and KDE Plasma desktop and experienced a similar issue on a new setup. After uninstalling bitwarden to switch my application manager (moved from snapd to deb-get, a tool that just downloads the .deb directly from github) and I received a spinning buffering circle of doom.

While @janvkn had to roll back to 2024.3.0 and delete the .config file on Arch. I can confirm that on Debian 12 and KDE Plasma version 5.27.5 all that is required is to delete the ~/,config/Bitwarden folder after uninstalling the snap and reinstalling. After that, Bitwarden has been functioning as normal.

For those using KDE and thus "using" kwallet as their secrets manager, there's another step that works for at least Arch users. In ~/.local/share/dbus-1/services/org.freedesktop.secrets.service (you probably need to make a few levels of directories):

[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/kwalletd6

A logout and/or reboot might be required but it worked like a champ after the above.

I can also confirm this works for non-KDE desktops using kwallet. In my case, using hyprland with kwallet as my secret store. Works great.

Good morning, I'm running bitwarden snap on Ubuntu 22.04. After doing all the manipulations -> still doesn't work. Remove /home/snap/bitwarden folder. Re-launch bitwarden -> OK.

Wow It worked for me. Many thanks.

Still getting this today - Chrome for Windows 126.0.6478.62, BW extension 2024.6.1

Version 2024.6.4 still requires Gnome-Keyring on Arch Linux.
@trmartin4 wasn't there something in the works, so it would be possible to fallback to local storage, instead the usage of a secrets-manager like gnome-keyring?

How's the progress? Has it already been implemented? If so, how can it be enabled/disabled?
We would like to dump gnome-keyring, since it only confuses our co-workers.