[Bug]: Sign in required after restarting hub since update from 3.12 to 3.16

[l0drex]

What Happened

When restarting Unity Hub, I have to sign in again. I should stay logged in.
The command line output shows errors connecting to kwallet, so I assumes its just dbus permissions missing. See comment.

How to Reproduce

1. Open Unity Hub
2. Sign in
3. Restart pc or quit hub from the system tray
4. Open Unity Hub again
5. I am not signed in

Operating System

Fedora Kinoite 43

Command-line output

Checking for beta autoupdate feature for deb/rpm distributions
Found package-type: deb
[2:0205/233449.209481:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.kde.KWallet.isEnabled: object_path= /modules/kwalletd6: org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown
[2:0205/233449.209514:ERROR:components/os_crypt/sync/kwallet_dbus.cc:113] Error contacting kwalletd6 (isEnabled)
[2:0205/233449.209806:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.kde.KLauncher.start_service_by_desktop_name: object_path= /KLauncher: org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown
[2:0205/233449.209813:ERROR:components/os_crypt/sync/kwallet_dbus.cc:82] Error contacting klauncher to start kwalletd6
[2:0205/233449.209953:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.kde.KWallet.close: object_path= /modules/kwalletd6: org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown
[2:0205/233449.209957:ERROR:components/os_crypt/sync/kwallet_dbus.cc:408] Error contacting kwalletd6 (close)
[70:0205/233449.392275:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:1631] vaInitialize failed: unknown libva error
LaunchProcess: failed to execvp:
xdg-settings
^C
[2 preload-host-spawn-strategy] Dropping 0x3e78000402c0 (3) because of connection closed
[2:0205/233726.368788:FATAL:dbus/bus.cc:1248] D-Bus connection was disconnected. Aborting.

Anything else?

I manually gave permission to communicate with the following sessison busses:

• org.freedesktop.DBus
• org.kde.kwalletd6

This successfully solved the issue.

[NoTuxNoBux]

Experiencing this similarly on GNOME now. Tried the changes from #177 on my end as well but it doesn't appear to solve it here; there also aren't any similar errors on startup and I see at least the default chromium secrets getting populated in the keyring successfully.

Something changed in newer Unity versions around login persistence, that's for sure - I suspect it has something to do with Electron updates and have also been looking at Flatpaks of other Electron applications but so far haven't found anything that solves it. I've also tried to diff the UnityHub config folder after logging out and in but also didn't spot anything out of the ordinary.

All I see in the logs is that the hub says No existing tokens found, which indeed implies it failed to save them on close.

EDIT: I do see this error but unless it's the precursor to some code that does the authentication saving it's probably unrelated:

{"timestamp":"2026-02-06T08:06:13.607Z","level":"error","moduleName":"SystemInfo","pid":2,"message":"Failed to retrieve hub executable path Error: Command failed: which unityhub\nwhich: no unityhub in (/app/bin:/app/bin:/usr/bin)\n\n    at genericNodeError (node:internal/errors:983:15)\n    at wrappedFn (node:internal/errors:537:14)\n    at ChildProcess.exithandler (node:child_process:417:12)\n    at ChildProcess.emit (node:events:519:28)\n    at maybeClose (node:internal/child_process:1101:16)\n    at Socket.<anonymous> (node:internal/child_process:456:11)\n    at Socket.emit (node:events:519:28)\n    at Pipe.<anonymous> (node:net:346:12)\n    at Pipe.callbackTrampoline (node:internal/async_hooks:130:17) {\n  code: 1,\n  killed: false,\n  signal: null,\n  cmd: 'which unityhub'\n}"}

This is printed around authentication on my system, which seems correct:

{"timestamp":"2026-02-06T08:06:13.622Z","level":"info","moduleName":"TokenManager","pid":2,"message":"Selected safeStorage backend: gnome_libsecret"}
{"timestamp":"2026-02-06T08:06:13.666Z","level":"info","moduleName":"TokenManager","pid":2,"message":"Using safeStorage with encryption with backend: gnome_libsecret"}

[l0drex]

Yeah, you probably don't have kwallet installed. Looking through the release notes, I found this:

3.16.0: Resolved a login issue affecting a small number of users.
3.14.1: Fixed an issue on Linux where some users were being logged out of the Hub.

Would be interesting to know what exactly these fixes are

[CaptainMirage]

im busy right now but if this problem isnt fixed in a few days ill just do it myself

[NoTuxNoBux]

Looks like it works fine for the AUR package, so it's not a bug on Unity's end. They probably changed something that indeed requires a new permission or file to be persisted.

EDIT: And now the Flatpak seems to stay logged in as well, despite me having cleared the cache and keyring entries of the AUR package and logging out and in again...

[CaptainMirage]

Looks like it works fine for the AUR package, so it's not a bug on Unity's end. They probably changed something that indeed requires a new permission of file to be persisted.

EDIT: And now the Flatpak seems to stay logged in as well, despite me having cleared the cache and keyring entries of the AUR package and logging out and in again...

god damn its been 2 weeks? and no thats not the problem

ive spent a full day debugging this on EndeavourOS / GNOME / Wayland with the Flatpak install, so i want to push back a bit on the "works fine" conclusion.

what ive ruled out:

• URL handler (unityhub:// correctly registered)
• missing packages (gnome-keyring and libsecret fully up to date)
• missing D-Bus permissions (org.freedesktop.secrets already in the manifest, confirmed in Flatseal)
• PAM config (gdm-password has all three pam_gnome_keyring.so lines including auto_start)
• clearTokensOnLogout in user-settings.json (flipping it to false does nothing)
• GNOME Keyring being locked (its unlocked, secret-tool round-trips fine)
• forcing --password-store=gnome-libsecret via flatpak override + nuking stale keyring blobs: login still doesnt persist across full reboot

what actually happens:
Unity Hub successfully writes an encrypted blob to GNOME Keyring (visible via secret-tool), but on next launch it cant read it back and forces re-login. this is an Electron safeStorage backend inconsistency that is as old as time at this point, the backend used to write the key differs from the one detected on the next launch, so the token cant be decrypted.

the AUR package working isnt surprising, it runs outside the Flatpak sandbox, so theres no portal/D-Bus boundary for the Electron credential layer to trip over. that difference is exactly what points to this being a Flatpak-specific packaging issue, not Unity's code.

if this doesnt get resolved soon ill look into fixing it in the manifest directly, but wanted to document the full picture first so whoever does fix it knows whats actually going on.

[imwil]

I use KDE so I don't know if this comment would help anyone, but here is my case.
I met this problem for a few weeks and fixed it a few days ago after having some free time to look into the issue.

So I took a look at VSCodium configuration in flatseal, which is working properly with the private keys. And comparing it with Unity Hub configuration, Unity Hub seemed like missing the permission of the kwallet (org.kde.kwalletd6) in the session bus. So I tried to add kwallet to session bus, and opened up kwallet manager to clean everything up. Then opening Unity Hub to login and it worked again when restarting, I don't have to relogin anymore.

Sorry if my english make you confused

[CaptainMirage]

I use KDE so I don't know if this comment would help anyone, but here is my case. I met this problem for a few weeks and fixed it a few days ago after having some free time to look into the issue.

So I took a look at VSCodium configuration in flatseal, which is working properly with the private keys. And comparing it with Unity Hub configuration, Unity Hub seemed like missing the permission of the kwallet (org.kde.kwalletd6) in the session bus. So I tried to add kwallet to session bus, and opened up kwallet manager to clean everything up. Then opening Unity Hub to login and it worked again when restarting, I don't have to relogin anymore.

Sorry if my english make you confused

hey, good find and it shouldve worked for you on KDE which it did, this lines up perfectly with what i found on GNOME (i was too lazy to test it anywhere but GNOME)

the underlying issue is the same on both desktops: Electron's safeStorage backend cant reliably reach the secret store from inside the Flatpak sandbox, so the encrypted token key cant be read back on next launch. on KDE that backend is org.kde.kwalletd6, on GNOME its org.freedesktop.secrets / the Secret portal. same root cause, different bus name.

what i found on GNOME is that even with org.freedesktop.secrets already in the manifest, forcing --password-store=gnome-libsecret via flatpak override and nuking stale keyring blobs still doesnt fix it across a full reboot. so its not just a missing talk permission on GNOME - theres something else going on with how the sandbox reaches the backend consistently between launches.

your comment is actually useful evidence that this is a sandbox/permissions issue in the manifest rather than anything on Unity's side, which is what i suspected already. the fix probably needs to explicitly cover both org.kde.kwalletd6 for KDE users and properly wire up the Secret portal path for GNOME users

probably will just make some dynamic system for this

[NoTuxNoBux]

Reopening since the PR wasn't intended to close the issue - it mainly fixes the secret provider used in KDE not being found, but on GNOME this wasn't the issue.

[NoTuxNoBux]

I can't reproduce this any more for some reason, but it's worth mentioning that 3.20 supposedly has a revised login flow using the system browser, so it may impact this as there might be other changes to the authentication flow, too.