Nextcloud desktop 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.

[github-actions[bot]]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[frankgerhardt]

I have this problem as well

[Schrottfresse]

Yes, the problem still persists for me, too.

[t-b-x]

Same here for me with client 3.2.1 on windows.

[github-actions[bot]]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[Schrottfresse]

The problem still persists.

[github-actions[bot]]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[T-bond]

No. Without a bugfix, it won't be solved, so stalebot, go back!

[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

[github-actions[bot]]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[T-bond]

@FlexW please mark it, so stale bot won't nagg everybody about new information. I think I have made a deep research on why the problem exists and what can be done in order to solve it. Unfortunately, I won't have time in the near future to fix it myself, but the issue won't solve itself.

[Slater91]

I have noticed this bug as well, but only in case I have set the system to automatically log in my user. It works fine otherwise. If I start Nextcloud at login with a delay it works fine. I hope this information can prove useful.

[hpfr]

Yeah, you can work around it, but the issue still should be fixed. If the secret service isn't available on launch, it should be possible to configure the client to wait, rather than automatically launching a browser, which can be pretty inconvenient. Most other apps using the secret service have a more graceful failure when secrets aren't available.

[mgallien]

I have noticed this bug as well, but only in case I have set the system to automatically log in my user. It works fine otherwise. If I start Nextcloud at login with a delay it works fine. I hope this information can prove useful.

what desktop are you using ? if you use a linux desktop and have pam setup to unlock your password storage then for that to work you need to enter the password (at least for Plasma desktop)

[mgallien]

Yeah, you can work around it, but the issue still should be fixed. If the secret service isn't available on launch, it should be possible to configure the client to wait, rather than automatically launching a browser, which can be pretty inconvenient. Most other apps using the secret service have a more graceful failure when secrets aren't available.

I am working on a possible fix for that. It may need a few more days before that is ready.

[hpfr]

I'm using KeePassXC's secret service feature, which is not integrated with a desktop environment, so I autostart it and sign in after login. Currently I autostart Nextcloud on a 60-second delay, which is fine, but ideally it would just autostart immediately and just silently fail until I unlock my database.

I am working on a possible fix for that.

Great to hear!

[Slater91]

I have noticed this bug as well, but only in case I have set the system to automatically log in my user. It works fine otherwise. If I start Nextcloud at login with a delay it works fine. I hope this information can prove useful.

what desktop are you using ? if you use a linux desktop and have pam setup to unlock your password storage then for that to work you need to enter the password (at least for Plasma desktop)

Yes, I am using KDE Plasma. The problem is that the password prompt doesn't appear, for whatever reason (bug in Plasma?), but Nextcloud displays a warning about the session being invalid and the need to re-login. It seems like Nextcloud doesn't wait for the password prompt to appear the way it does with manual login. I look forward to trying the fix!

[Schrottfresse]

@mgallien Sorry to nag, but do you have an update for this issue?

[alan-w-255]

I just fixed it by installing the gnome-keyring on my archlinux. I hope it helpful.

[ShayBox]

Same problem, already have gnome keyring installed, it logs out every boot and randomly while syncing

[Schrottfresse]

So, I fixed it with an ugly workaround. I just edited the Nextcloud client .desktop file and changed the Exec line to this:

Exec=/bin/bash -c "sleep 5 && /usr/bin/nextcloud --background"

[PowerUser64]

Has anyone been able to solve this?

I recently started getting logged out of any desktop client when I reboot. It happens on every desktop client I'm logged into as well as the NC Dev mobile app. Not on the web UI though. I thought using TOTP might have something to do with it, but disabling it changes nothing.

[artfulrobot]

I'm getting this too now. Wasn't a problem before 3.5.2 (though I can't recall what I was using before 3.5.2, sorry). I'm on Ubuntu + Gnome, and using the AppImage

Every time I log in it has to pop open browser links to authenticate again.

[ericfischerbav]

I can confirm this problem occurs with client 3.5.2 on a XRDP session. Downgrading to 3.5.1 solved my problem, since in this version there is a system promt to unlock my keyring. I'm on Linux Mint 20.3.

[artfulrobot]

The delayed start suggestion at https://github.com/nextcloud/desktop/issues/2573#issuecomment-1036523508 by @Schrottfresse did not work for me. But downgrading to 3.5.1 did work, as @ericfischerbav reported.

[j-seq]

Same behaviour here on a Debian/Mate w/ gnome-keyring 3.36.0-1: Nextcloud-3.5.1-x86_64.AppImage works fine; Nextcloud-3.5.2-x86_64.AppImage asks for KDEWallet every time.