-
Notifications
You must be signed in to change notification settings - Fork 793
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: 3.14.0/3.14.1 asks to log in on every start #7231
Comments
Also having the same problem. Had to revert back to 3.13.4 |
Not being familiar with Ubuntu Mate 22, do you what is supposed to be storing secrets on this platform ? |
Appears to be the same experience on standard Gnome Fedora 40. I've even had to reenter the E2E numonic forcing a resync Which raises the question, does it work for people who have plasma for their Desktop? |
I'm experiencing the same issue with two ubuntu noble 24.04.1 installs using appimage. |
Same for me (LM22 Cinnamon). I'm asked for a kdewallet password. I never used kdewallet. |
Same with Ubuntu 24.04.1, appimage. |
+1, Ubuntu 24.02.1, appimage 3.14.1 |
Same here (Ubuntu 24.04.1, using Nextcloud AppImage 3.14.0 or 3.14.1), it also crashes with segmentation fault regularly. Rolled back to 3.13 |
Confirmed on LM22 (Noble base). |
+1 |
I've the same issue in Debian SID ... I'm not using kdewallet at all. |
Same with ubuntu 24.04.1 and NextCloud AppImage 3.14.0 and 3.14.1, the latter version fixing nothing. |
Where to find the previous AppImage please ? |
Just chiming in to say I have had this problem too, with both 3.14.0 and 3.14.1. I'm using Ubuntu 24.04.1, GNOME 46, and the NextCloud AppImage. 3.13.4 continues to work as expected, so I have rolled back to it after both updates and am staying there for now. |
Got the same problem since doing the dist upgrade to 24.04.1 today, |
Having this problem since 3.14.0, updating to 3.14.1 didn't fix it. |
Confirm same problem here on LM22 since 3.14.0 |
Same here, Fedora 40 + 3.14.0 and 3.14.1 reverted to 3.13.4 and fine with it. |
please avoid posting too much comments without more information |
and by the way, I did not notice because I have kwallet configured and running |
Fact: There was no problem with 3.13.4. There is a problem with 3.14.0 and 3.14.1. If I go back to 3.14.3, the issue disappears. Comments: I don't know if kwallet is installed. What is the name of the package ? Not kwallet obviously, the package does not seem to exist. Besides, I use Ubuntu with Gnome. I suspect that kwallet belongs to KDE. Not everyone uses KDE. There is a place where secret are stored with Gnome. The old version 3.13.4 does put the secret in this place. Not the versions 3.14.0 and 3.14.1. Something is clearly broken in 3.14.0 and 3.14.1. |
the release 3.14.1 is working fine with ubuntu 22.04 stock installation and my question is for anybody that want to help not just @phi0042 |
as I cannot reproduce with ubuntu 22.04, you have to know that I will keep working on this only if the tone of the conversation is nice, respectful and useful |
@mgallien these are the lines in my logs that contain the string 'error' (case insensitive) :
gnome-keyring-daemon is running. I cannot find any lines in my logs mentioning storage of secrets. What's the pattern I should be looking for? |
The explanation is simple by searching the forum : with 3.14, Gnome Keyrings is not detected/used anymore for some reason. Which is what I wrote earlier : with 3.14, the secret is not stored anymore for some reason. This means that anyone using Ubuntu 24.04 with KDE will not have any issue. As for the log file, it is huge. |
Fedora 40 with Gnome shell 46.5 $ sudo dnf list installed | grep kwallet I don't remember installing kwallet. It has not been configured or any rings created that I know of. Just from retrying and app registration against browser login. The below two are from initial startup |
|
Even if installing kwallet is valid work around, supporting Gnome's built in solution should be viewed as a must. Gnome or desktops based on gnome are the default backend of the most popular linux desktop distros by a large margin. Its something that should just work. That it works with KDE tools is great! But it cant be the only solution |
Some details about my case if it can helps : Here is the complete log of the desktop client :
And a screenshot of what happen when I launch the AppImage from a CLI : Xubuntu v24.04.1 LTS (noble) Reverting to Nextcloud v3.13.2 desktop client solves the problem |
English is not my mother tongue. KDE Wallet is for KDE what Gnome Keyring is for Gnome, a place to store secret.
|
In version 3.14.0 The workaround/fix from frankosterfeld/qtkeychain#211 (comment) seems to work [1]. [1] On Ubuntu 24.04.1, extract nextcloud appimage using |
Using 3.13.4 seems to fix this for everyone, yet for me it started recently and I never upgraded to 3.14 at all. Could it be related to me having uninstalled gnome-keyring. I removed it toreplace it with a different secret service provider. |
The workaround proposed by @jvanderneutstulen works very well. |
I confirm this works on my LM22 build, but I have a question. Do I need to rebuild the appimage using your second quote above or do I just run the binary from the ./squashfs-root folder each time I start the computer? |
I would think it would be fine, but if you want you can make it an appimage again with Or in mycase I downloaded the appimagetool.appimage and ran |
It's a very good idea. But despite my effort, I cannot find where to find the binary appimagetool-x86_64.AppImage. |
The workaround worked very well for me. @phi0042 you can find appimagetool here: https://github.com/AppImage/appimagetool/releases |
Workarounds are nice. I still hope for a solution from Nextcloud that would also survive the next client update. |
I can't tell my users to unpack and edit Appimages. Can someone look into this and run a build for Ubuntu 24 and derivatives? |
@jaykayenn : I don't understand what you want. I made a new AppImage and you can as well and give it to your users. |
Thanks for this, works perfectly. |
I think we are in all agreement that officially supported releases simply should work without any additional fixes by the end user or their support staff... |
Bug description
Every time the desktop client starts, it opens a browser window asking me to authorize it with my Nextcloud instance. Downgrading to 3.13.4 fixes the issue (the client logs in immediately and transparently upon starting). The issue persists in 3.14.1.
Steps to reproduce
Expected behavior
If I've logged in previously, I should not be asked to log in again when the client starts
Which files are affected by this bug
n/a
Operating system
Linux
Which version of the operating system you are running.
Linux Mint 22 Cinnamon
Package
Official Linux AppImage
Nextcloud Server version
29.0.7
Nextcloud Desktop Client version
3.14.1
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 3.3.6 to 3.4.0)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
Are you using an external user-backend?
Nextcloud Server logs
No response
Additional info
I don't want to post a full debug archive since it contains information I'd consider sensitive. Here's some relevant logs though:
The text was updated successfully, but these errors were encountered: