Client needs to manually login after every start

[Schrottfresse]

Expected behaviour

Nextcloud desktop keeps logged in after first successful login.

Actual behaviour

Nextcloud desktop keeps asking to log in on every start up.

Steps to reproduce

1. Launch Nextcloud desktop client.
2. Log in via a browser.
3. Exit Nextcloud desktop client or reboot.
4. Launch Nextcloud desktop client.

Client configuration

Client version: 3.0.2 (Arch) (git revision 068ad8)

Operating system: ArchLinux

OS language: German

Qt version used by client package (Linux only, see also Settings dialog): Qt 5.15.1

Client package (From Nextcloud or distro) (Linux only): distro - community/nextcloud-client 3.0.2-1

QtKeychain version: qtkeychain 0.11.1

KWallet version: kwallet 5.75.0

Server configuration

Nextcloud version: nextcloud 20.0.0

More information

I have seen issue #2260 and added information about QtKeychain and KWallet.

I can see that nextcloud-desktop tries to authenticate, but it only starts trying after I unlock my kwallet. Also I see some credentials in my kwallet regarding nextcloud-desktop. So I assume that kwallet is working correctly.

[er-vin]

And after startup, when it asks for the login, if you ignore this, quit it then launch the client again, what happens then? Does it ask for the login still? or it authenticate fine?

[Schrottfresse]

It authenticates fine. So this is a race condition, you think?

[er-vin]

Looks very much like it yes. I think nextcloud-desktop somehow starts first, try to poke at kwallet (via qtkeyring), nobody answers so it goes through the login procedure you see. Then kwallet finally starts but somehow it's "too late".

I'll have to think at how we address this.

[T-bond]

I think I have a very similar issue. I am not sure if it is different than this one, if so, and someone would like me to open it as a new issue, I will do.

I am also using Arch linux:
nextcloud-client 3.1.2-1
qtkeychain-qt5 0.12.0-1
kwallet 5.78.0-1
keepassxc 2.6.4-1
The only difference I am using KeepassXC instead of Kwallet.

My kwallet is disabled with the following config:
~/.config/kwalletrc

[Wallet]
Enabled=false

Also KeepassXC is set up to function as a secret storage backend. It is working correctly, as for example IntelliJ products can store and read entries in it, and another applications are working correctly too.

First time running the Nextcloud client (and logged in to KeepassXC) I followed the web auth login.
But after a reboot, it always asks me to redo the web auth procedure. If I close the Nextcloud client (without doing the web authentication again), type in my KeepassXC password (to unlock the key store) and start the Nextcloud client again, it can read the secrets from the store, and can reauthenticate without needing to follow the web flow.

So the issue is, that while I don't unlock my keepass store, the Nextcloud clients tries to authenticate through web.
(And of course I could not open my store after boot, as I don't have enough time to type in, as Nextcloud clients is auto started with boot too.)

Would it be possible somehow, to the Nextcloud client, to detect if the secrets are available through libsecret, or somehow invoke the attached secret storage backend, for unlocking, instead asking for web authentication?

Edit: A temporary fix would be to add an option (a config entry in an ini file would do the trick) to disable Web auth, and only try to read the credentials from the libsecret. So if I am away from my computer when it turns on, and go there for example 5 minutes later and open my keystore then, nextcloud could try to read the credentials in 30second interval. Or with some interval, and if it finds it can connect with it.

Edit2: I have been thinking more about it. Maybe this workaround could work pretty well. I think there is no way to ask libsecret if it has openeded or not. I need to check it later.
So a more refined workaround would be:
If the application is able to save the credentials into a keystore, it would save that it successfully used a keychain.
Next start it would check if it was able to store the credentials. If it was, then now it would only try to load from the libsecret, and won't ask for webauth. Also an option could appear in the account settings to open a webauth. (Which could also set back the setting that only use libsecret on start. It would allow using webauth only again, for example if the user do not want to use the keychain in the feature.)
If it can save again to a keychain, than again, we could store this info, and start all over again.

I hope I was clear, and if somebody tries to solve this issue, and don't find a better solution would implement this.
Unfortunately I don't have much time to implement myself, also don't know the codebase.
But I would be interested, if a PR would be opened with this solution, would it be allowed/merged?
Or does the maintainers have another idea?

@er-vin what do you think?
Currently it is so annoying that it opens a dialog, a new webpage (for webauth), after I close these, I had to close the app too, and after I unlock my keystore, I need to start the Nextcloud app again.
But maybe if I would disable the auto start on system start it would not annoy me as much 😀. But it still would not be ideal.

Update: I checked the QtKeychain implementation. I think libsecret provides information if it is unlocked or not, but Qtkeychain interface hides this information, so there is no way to check if the used store (for example KWallet or Libsecret is opened).
Thus I think my workaround is still the best solution for this problem.
I started to check the Nextcloud Desktop code base, but I don't think I can find the time in the near future to implement my idea, and even if it would be allowed to be merged.
It would be good to hear back from the maintainers.

[t-b-x]

Same here for me with client 3.2.1 on windows.

[hpfr]

@FlexW Is this still planned for 3.3? The tagged release candidate doesn't address many issues in the milestone?

Edit: Looks like the release got updated with a bunch of merged PR links, but nothing with this, unfortunately

[lapineige]

No the case for me with Plasma 5.27.4 and Nextcloud 3.8.0, Kubuntu 22.10.

[anewb]

I had the same problem with a fresh install, Nextcloud Client 3.8.1 on Ubuntu 22.04 (Tuxedo OS 2), KDE Plasma 5.27.4.

I did some testing and found 2 possible solutions for me:

• Installing gnome-keyring (sudo apt install gnome-keyring) DID fix the problem, and after checking the 'automatically unlock when i sign in' box, Nextcloud Client does automatically log in after every restart.
• Alternatively KDE Wallet did work too, after some trial-and-error. It was already installed, but no wallet had been created. I created the wallet named 'kdewallet' and used my user password as wallet password. Wallet name and password are important, otherwise it can not be unlocked automatically (see here). Then in System Settings - Personalization - KDE Wallet - Wallet Preferences i set Enable the KDE wallet subsystem, Select wallet to use as default to kdevault and Use KWallet for the Secret Service interface. With that, the wallet was automatically unlocked after restart and Nextcloud Client was able to successfully use it for credential storage.
• KDE Vaults did not work for me.
• Introducing a startup delay like recommended here did not fix the problem for me.

[kunsel]

Same problem for windows client.
O/S: Windows 10 Home, Version 10.0.19045 Build 19045
Client: 3.8.2

[llitz]

I have this problem in Gentoo Linux using Sway and nextcloud-client version 3.7.3.

I have been experiencing recent issues with nextcloud not communicating with gnome-keyring-daemon.
These have been fixed by upgrading to qtkeychain-0.14.0

[Gahia123]

I have this problem in Gentoo Linux using Sway and nextcloud-client version 3.7.3.

I have been experiencing recent issues with nextcloud not communicating with gnome-keyring-daemon. These have been fixed by upgrading to qtkeychain-0.14.0

How do you manage Nextcloud password with gnome-keyring-daemon? I've installed, but not being able of using it.

[llitz]

Nothing special, I think? I start gnome-keyring-daemon with sway and update the dubs environment, but even manually starting it then starting nextcloud it works for me.

[Gahia123]

I deleted Nextcloud cache folder and run:
gnome-keyring-daemon -s
nextcloud
Still need to authenticate every new session. Is there another possible cause?

[then4p]

• Alternatively KDE Wallet did work too, after some trial-and-error.

There needs to be some kind of error message to notify users of a missing wallet on KDE. Might this be some configuration error on Tuxedo's part? I've never run into this issue before on Kubuntu or EndeavourOS with KDE. Maybe those distros ship with a default kdewallet enabled.

[ZID-TU-Graz-Collab]

We are also affected by this issue: The problem with gnome-keyring also occurs on Debian 12 bookworm.

[tuxuser]

For Gentoo users, ensure to have use-flag +keyring set for dev-libs/qtkeychain, naming got changed.

[dev-libs/qtkeychain: Rename USE=gnome-keyring -> keyring]
2023-05-18

Reference: https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-libs/qtkeychain?id=95811d5b5d1d46289f05c53a2299fe0a4f99a152

[sfatula]

I have the same problem on Raspberry PI OS, which is based on Debian 11. None of the solutions here worked. This is with flatpak as I don't see a arm64 appimage. 3.10.0

[ibizaman]

Not a fix but a bandaid: I just added a delay when starting the Nextcloud client systemd service by following https://stackoverflow.com/a/52592734/1013628

[maaikez]

I have the same problem on my laptop. I use nextcloud client on laptop and desktop. Both have archlinux. Both have qtkeychain-qt5 installed. On my desktop I run lxde, on my laptop xfce as far as I know. I don't know what other differences there are.

A difference might be that my laptop normally does not have an internet connection yet on startup, my desktop has. However when I do not auto start, it will still use the browser on my laptop.

[edit] Found out why: my desktop had gnome keyring installed, the laptop did not. Installing gnome keyring helped solving the issue. But now I need qtkeyring-qt5 (which installs kwallet) AND gnome keyring, which is quite strange.

[JappeHallunken]

I had the same problem on DietPi (based on Debian) with LXQt and I installed gnome-keyring, which solved the problem for me!

[amandasystems]

I had this problem on Fedora Kinoite too, where KWallet, an application I didn't know existed, was apparently turned off by default which caused this behaviour. There really should be a warning dialog instead of having the account authentication getting corrupted on application restart.

[Travis-Ecc]

I've only recently had this start happeing to me also. Didn't know about kdewallet. There are no keys in it.
I'v eonly noticed this in last few days but computer has been off for a week or so.
Client requires sign in.
Fedora 40 Workstation
Nextcloud client is AppImage
After closing out of kdewallet and closing the client I can reopen it

[il-santo]

I have both gnome-keyring-daemon and qtkeychain installed on Fedora 40, but this problem still persists.

[storca]

I'm having the same issue in Ubuntu Budgie 24.04.1 LTS using desktop client 3.14.1

When I open the client for the first time to login, an extract of the contents of the log file filtered by "keychain" is as follows :

2024-10-03 20:48:52:771 [ warning nextcloud.gui.account.manager /home/user/src/gui/accountmanager.cpp:536 ]:	Failed to read proxy password to keychain "Unknown error"
2024-10-03 20:48:52:771 [ info nextcloud.sync.credentials.webflow /home/user/src/gui/creds/webflowcredentials.cpp:139 ]:	Fetch from keychain!
2024-10-03 20:48:52:777 [ info nextcloud.sync.credentials.keychainchunk /home/user/src/libsync/creds/keychainchunk.cpp:346 ]:	Backend unavailable (yet?) Retrying in a few seconds. "Unknown error"
2024-10-03 20:49:02:966 [ warning nextcloud.sync.credentials.keychainchunk /home/user/src/libsync/creds/keychainchunk.cpp:360 ]:	Unable to read "myuser_clientCertificatePEM:https://example.com/:0" chunk "0" "Unknown error"
2024-10-03 20:49:02:966 [ info nextcloud.sync.credentials.keychainchunk /home/user/src/libsync/creds/keychainchunk.cpp:346 ]:	Backend unavailable (yet?) Retrying in a few seconds. "Unknown error"
2024-10-03 20:49:12:967 [ warning nextcloud.sync.credentials.keychainchunk /home/user/src/libsync/creds/keychainchunk.cpp:360 ]:	Unable to read "myuser_clientKeyPEM:https://example.com/:0" chunk "0" "Unknown error"
2024-10-03 20:49:12:967 [ info nextcloud.sync.credentials.keychainchunk /home/user/src/libsync/creds/keychainchunk.cpp:346 ]:	Backend unavailable (yet?) Retrying in a few seconds. "Unknown error"
2024-10-03 20:49:22:967 [ warning nextcloud.sync.credentials.keychainchunk /home/user/src/libsync/creds/keychainchunk.cpp:360 ]:	Unable to read "myuser_clientCaCertificatePEM0:https://example.com/:0" chunk "0" "Unknown error"
2024-10-03 20:49:33:355 [ warning nextcloud.gui.account.manager /home/user/src/gui/accountmanager.cpp:367 ]:	Failed to delete proxy password to keychain "Unknown error"
2024-10-03 20:49:35:064 [ warning nextcloud.sync.account /home/user/src/libsync/account.cpp:823 ]:	Unable to store appPassword in keychain "Unknown error"

The last line mentions that it was unable to store the password in the keychain, even though the gnome keychain is installed on my system.

[danepowell]

For folks that just started to experience this recently, it's a regression: #7231

[Chad90b]

I'm experiencing a similar issue on client v 3.14.3 for Windows 10 64bit. Should I make an entirely new issue for that?