Client always asks for authentication #1716
Comments
|
This has been troubling me too for the past two weeks or so, although sometimes it does work. Server version: 15.0.13 Both log files contain the error In my case, the app segfaults immediately after login. |
|
I have similar behaviour on Windows 10 with Client 2.6.2 I don't need to login after every single client restart, but every 1-2 day or so This didn't happen with older Nextcloud client versions |
|
I'm having the same issue on Linux Mint 19.3 (Xfce if that matters in any case) which is based on Ubuntu 18.04.1. After every reboot Nextcloud is asking for authentication. libgnome-keyring0(was a dependency so it came preinstalled) and libgnome-keyring-common won't fix it. Didn't try the AppImage yet but that's not really an alternative for me. If you need any further details (logfiles e.g.) let me know. |
|
Can confirm with |
|
I have the same problem. |
|
Does not happen on my other machine (Arch) also running 2.6.2git but with the difference that I set it up using an older client and server version. |
|
Same issue here on macOS. |
|
Same issue, Windows 10. Happens every 1-2 days. Started once server was updated from 16 to 17, although it could still be tied to client version. Client version: 2.6.3 |
|
Also upgraded from 2.6.2 to 2.6.3, problem still exists. |
|
Same here with KDE neon 5.18.2, clients 2.6.3 and 2.6.4. I have 5 accounts at the moment and need to re-authorize those at each and every boot - can we upvote this as "Most Annoying Bug"? |
|
It was debugged some time ago #1292 (comment), but it seemed to be fixed only in Fedora. It certainly is a very annoying bug, pretty extended.. It may be worthwhile investing a little more time on it :) |
|
Honestly, I already lost hope on this... :) |
|
In the meantime i was able to mitigate this problem by installing gnome-keyring - anyway, not certain which side effects this might have. |
|
I am having this problem on Arch Linux machine, while everything is ok on 2 Win10 machines. |
|
@epsilontheta and the others, can you confirm that this is a duplicate of #1292? |
|
I'm no longer getting this issue, most likely since update 17.0.4. |
|
How about the others? Most seemed to be using Linux setups. |
|
Still have the same problem on all (3) KDE machines. |
|
I don't know actually. OS: macOS |
|
KDE key storage seems to differ frome GNOME. Might be Nextcloud only handles the GNOME way correctly. This would explain why installing GNOME packages seems to solve the problem. Correct me, if I'm wrong. |
|
@claell yes that is the same bug except that I did not have this delay where it shows "no connection". After installing |
|
The same here (gnome-keyring "fixes" the problem) - #1292 (comment) - but I really don't want to install this stuff on my KDE system just for NC to work. |
|
Hm, I am not sure how to track this, as it might have a different cause than #1292. Currently it seems unclear, whether #1292 was actually fixed but there are issues with other environments (then it might be closed and the issue on other environments can be tracked here) or whether #1292 was not fixed properly (then this would be a duplicate and all should be tracked in #1292). I will leave both issues open for now. |
|
Can confirm the problem for both of my systems. |
|
Same issue with Gentoo Linux and i3 WindowManager. Extremely annoying. |
|
I observe this issue with the latest version of the Nextcloud client on Windows 10, Debian Buster with KDE Plasma, and macOS 10.13. It is a very annoying behaviour. I never experienced this behaviour with the OwnCloud client, where I could explicitly specify the app-specific credentials in the client. |
|
Please, give us an option to store credentials encrypted inside the application. |
Confirm this. I've just switched from elementary OS (with the Pantheon desktop) to Ubuntu 20.04 (with GNOME), and the issue is gone. |
|
Same issue on Manjaro Stable (Fluxbox Desktop). |
|
Win10 with desktop client v2.6.4stable-Win64 (build 20200303); NC v18.0.4 and the problem persist |
|
Same issue with version 3.1.1. Running arch with swaywm. Installed libgnome-keyring after reading up on the issue tracker. It didn't help. Got libsecret and qtkeychain installed. Really annoying issue, as this really defeats the whole point of the desktop client. |
|
I was actually debugging a separate issue, and managed to fix this (at least in my case, there seems to be many different causes). I was running my server behind an nginx ingress in Kubernetes and kept getting errors about an insecure redirect from https to http when authorizing new apps. I fixed that by adding to my config.php, and after adding that, my clients were able to consistently sync again. No keychain or libsecret changes. EDIT: To clarify what I was experiencing, this issue was occurring on Windows and Linux, which was what led me to believe the issue was server side. There may still be unrelated issues on certain Linux distros that are causing the same symptoms. I was also getting 401 errors during the oauth login process, whenever a client tried to authenticate. |
|
I'm still having this issue with Arch Linux. Even with gnome-kering and libgnome-keyring. |
|
@MeisterLLD are you sure your keyring is configured correctly and gets unlocked properly? libgnome-keyring is deprecated you should use libsecret instead. I use ArchLinux with gnome-keyring too and don't have this problem. I will close this issue for now as I think that everything works as expected. Everyone who has issues with that (especially people that use custom ArchLinux setups;)) are encouraged to check if the really configured their keychain correct so that it gets unlocked properly when they login. Please feel free to reopen or create a new issue if new problems occur. |
|
You are right, my bad, after another verification I found out that my keyring was not properly configured. |
|
Still experiencing this issue on Windows 10 and Windows 11 machines with the latest client version |
|
This is happening with client 3.4.2 (macos) on MacOS Monterey (12.2.1). |
|
I just experienced the same issue on Arch Linux, although, a reboot solved it (for now, but I hope it won't come back). nextcloud -v gave this: |
|
I solved this issue on arch linux with kde plasma. For me it was as simple as configuring kwallet. But I know others aren't so lucky. |
|
I solved this too on Tuxedo OS with KDE. KDE Wallet subsytem was not enabled. After I have enabled it, everything worked correctly. |
and others
Expected behaviour
After authenticating once with the browser based scheme it should remember the credentials and use that when starting the client the next time.
Actual behaviour
It always asks for credentials at start.
Steps to reproduce
Client configuration
Client version: 2.6.2
Operating system: Fedora 31
OS language: English
Qt version used by client package (Linux only, see also Settings dialog): Qt 5.13.2
Client package (From Nextcloud or distro) (Linux only): nextcloud-client-2.6.2-1.fc31.src.rpm
Installation path of client: /usr/bin/nextcloud
Server configuration
Nextcloud version: 17.0.2.1
Storage backend (external storage):
Logs
Client logfile: https://gist.github.com/epsilontheta/6ddfd7b1057e19562a57e061a7f4abb6
Web server error log:
Server logfile: nextcloud log (data/nextcloud.log):
The text was updated successfully, but these errors were encountered: