Dear all, first of all, thanks a lot for the great software you build and we use and build a community for.
I’ve experienced often a problem with the KWallet KDE Wallet Integration. Namely, the Nextcloud client would start and ask for a password every time. KDE wallet would also ask for a password to unlock it for the next cloud.
The potential reasons for this might be: OS update, Client update, Migration to a new machine. I am not sure,
what exactly happens there. But the result was that there were some nextcloud eintries in the wallet but they were not used.
A SOLUTION for me was to 1) Stop the client, quit it; 2) Open the wallet, locate the Nextcloud entries, remove all of them (there were 2); 3) Relaunch nextcloud client, relogin. And then after following relaunches it just worked.
But it does not work for me in proper way. NC ver 15.0.5 installed on QNAP NAS (64 bit, Intel 4 core, 16 GB RAM, MySQL as DB) Linux client ver 2.5.0. The same problem on two desktops and laptop. It worked properly in former version (14.X.X) of NC (with the same clients version). Now if Im not so hurry to enter in 5 sec pass to unlock kwallet, login web window appears (see attached picture). Is any possibility to make NC Client to wait until kwallet will be unlock? And do not display de facto WEB login window so it is necessary to login again. Any idea how to resolve the problem?
Seems like my solution is not a reliable one.
Next cloud pops out the authentication dialog in parallel with the kwallet dialog. After unlocking the kwallet the next cloud dialog stays opened (it is a bug) but the client is actually logged in at the sane time, buggy behavior…
Next cloud team, wie kann man Euch bei dem Bug helfen?
I experience the same issue. The problem is that Nexctloud wants to authenticate before kwallet is unlocked. Since the nextcloud client cannod receive the credentials from kwallet, it thinks that it is kicked out and requests nextcloud login again.
The best solution would be that nextcloud is waiting for kwallet to unlock.
The issue is tracked at Github, where you can also find a workaround.
