[Bug]: nextcloud 3.5.2/3.5.3 appimage always requires authorization #4715
Comments
|
I can confirm this, I have reproduced the issue. |
|
I have the same problem but with differences from the issue as reported above:
|
|
Same issue here after upgrading from 3.5.1. Except the OP forgot to edit the repro steps and expected behavior, which were copied from the bug template. Has nothing to do with sharing. |
|
same here. Linux Mint 20.3 |
|
Také zde ubuntu-5.4.0-121-generic |
|
I have the same problem on Fedora 36. |
|
same issue on Ubuntu 22.04 + Fedora 36 also if authorized it is considerably slower than the previous version! Opening settings requires several seconds. Up to 3.5.1 it just worked so I returned to that. |
|
Experiencing this same issue on Ubuntu 20.04 connecting to a Nextcloud 23.0.6 server. Works again with the old 3.5.1 AppImage. |
|
I have the same issue using Nextcloud-3.5.2-x86_64.AppImage desktop client on my device which is running Linux Mint 20.3 cinnamon (Kernel 5.4.0-122-generic). Nextcloud Server version is 24.0.2 |
|
Hi, |
|
Same issue on my Gentoo with GNOME 42. Moreover, it continuously asks to store credentials in the KDE KeyWallet. Iade |
|
same for me |
|
Same on debian bullseye (with backports) using the 3.5.2 AppImage. I'd like to add that the whole app seems unresponsive. For me it takes quite long until the windows pop up requesting authorization. When trying to open the settings window by clicking "Settings" from the main menu, it also takes very long until the settings window pops up. |
|
After installation of Version 3.5.2 I had to login at every start. When installing 3.5.1 again, only the first start needed a login, as before. |
|
Same problem here, my nextcloud desktop (3.5.2) is freshly installed through snap on Ubuntu 22.04. I have two accounts so the authentication process is really painful... |
|
Same issue here with version 3.5.2 (AppImage). Was no problem with 3.5.1 and going back to 3.5.1 solves the authorization issue. Maybe the issue is somehow related to https://github.com/nextcloud/desktop/issues/2573 |
|
I checked what was requested on d-bus:
Looks like they moved from the generic d-bus Secret Service API to the special KDE version of it. Introducing a breaking change in a minor version update without a big fat warning is not nice.. |
No but it is typical for this app. |
As I understand your discovery, @rupi-lol , I assume that means:
Is there a possibility that this "breaking change" happend unintentionally? |
tigernero79
changed the title
|
unfortunately this bug is still present even in the new version 3.5.3 😢😏 |
If everybody in development and testing uses KDE it may be that nobody even realized what they had done. Would not be the first time something like that happens and I can totally see this slipping through testing. What I find problematic is that they seem to ignore this issue... will this change rolled back? Do we need to find another sync solution? .. Some kind of comment by a dev would be really appreciated. |
|
I had experienced another even worse access issue with ssl config (login failed) , and they ignored it for months. I had to run the old version forever. I suspect they have very limited resources, and unfortunately they may not be an experienced dev working on this area of the code, which is horrifying for such an important aspect of the solution. If anyone can share the process to get to an older build on Ubuntu 20 lts that would be appreciated |
|
Just noting I'm having the same issue too. 3.5.3 appimage on Ubuntu 22.04. I can confirm that revering back to 3.5.1 works though. |
|
I have no experience in C++ or the Qt framework so I'm a bit lost in debugging this. But: a quick look in https://github.com/nextcloud/desktop/tree/master/src/libsync/creds (the only place in the code I found dealing with keychain connections) showed no change at all. So I tried to build nextcloud desktop 3.5.3 against the Qt5 shipped with my system (Debian 11.4, current stable): no problem at all, uses d-bus Secret Agent API. So it looks like the bundled qtkeychain is at fault here. |
I don't think so. Provided they're still building AppImages the same way, they're still using qtkeychain v0.10.0 from 2019. |
|
The authorization issue persists in version 3.5.4. Also, opening the settings window still takes several seconds as mentioned by @Cuthbert1337. |
|
After discovering that the build script uses a public available docker image as build envirionment I tried it and built a current snapshot appimage: the authorization issue is there. And as @moppman saw it uses qtkeychain v0.10 (same as I did with my local build). So the culprit left would be the linuxdeployqt appimage used. |
|
Confirmed the problem derives from linuxdeployqt. Built an appimage with |
|
I respect those who put effort, time and dedication to make it possible in this case to use a functional client for nextcloud. but I wonder is it possible that no developer from the 3.5.2 release today we are at 3.5.4 has the slightest thought of testing appimage on a Debian distribution? because it is absurd that after 2 version releases no control by nextcloud has solved such an obvious problem. these are the problems for which one then asks does it make sense to use free applications? I say after 2 version releases who does tests? |
can you describe how you built it? so which docker container to spawn and then run the linked script from @moppman? and thanks for opening an issue at linuxdeployqt <3 |
|
@x29a Checkout https://github.com/nextcloud/client-building and then run Edit: You'll need to adapt |
|
It makes me wonder if the Nextcloud support people are even monitoring this thread / channel. It would appear from @x29a 's solution above, that this is a trivial problem to fix, yet it has been present in 2 releases since it was first reported. I can confirm that it is still present on 3.5.4 running on LinuxMint 20.3. |
|
@moppman thanks for the pointer, with that i verified @FredericLespez PR #103 of the clientbuilding project and it works just fine. What a relief! @pnewbery im not sure how to raise more awareness for this issue. Somebody stated somewhere the forums, though there is an entry already. While searching for this problem i stumbled accross this debian bug - not sure if people there could help. |
|
The issue still persists on version 3.5.4 on Ubuntu 22.04.1. |
|
I'm using 3.6.0 AppImage and the issue persists, It asks for authorization everytime I open the app. |
|
NOT FIXED in Appimage 3.60. Now being asked for keyring login on Linumint 20.1 |
|
Appimage 3.6.0 with Debian fixed the issue for me. |
|
OK, I've just discovered what I think is the reason for the login keyring always asking for my password before Nextcloud will connect. |
|
Check the documentation and bugtracker for Seahorse to see if the issue had
been previously report.
…On Fri, Nov 11, 2022, 4:25 AM pnewbery ***@***.***> wrote:
OK, I've just discovered what I think is the reason for the login keyring
always asking for my password before Nextcloud will connect.
I was doing a bit of surfing looking for possible answers and one of the
topics I found mentioned Seahorse. I opened Seahorse to check the entries
in my keyring and found that I had two Nextcloud app passwords for each of
the two servers the client logs into. I've no idea how this has occurred
and can only surmise it happened because of all of the issues I experienced
with the appimage. Now I'm faced with the issue of knowing which is the
correct appimage password for each server and which one to delete or
whether to start all over again. However I'm not sure how to do that. I
suspect that if I delete all of the Nextcloud keyring entries, the solution
may present itself, but could someone confirm this please?
—
Reply to this email directly, view it on GitHub
<#4715 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANUKZSCR2IM6LXI4ZE6ARDWHY3KPANCNFSM53EJTB3A>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I also have this issue I noticed Nextcloud saves 2 entries to my secret service provider (KeepassXC) although I only connect to one server. I then tried deleting one of the two nextcloud entries (the first one, did not work if I deleted the second one) in the secret service, started nextcloud and it used the remaining entry without requiring confirmation. But it readded a second entry after which the next restart required confirmation again. If I deleted that most recent added entry the next restart worked fine again but added the (wrong) second entry and so on. So I assume there is an issue with the two entries being created by nextcloud. |
|
That issue was supposed to be addressed in keepassxc. See their bugtracker
on github. Some managers such as kwallet do not support secret service
…On Fri, Nov 11, 2022, 8:39 AM ppascher ***@***.***> wrote:
I also have this issue
> nextcloud -v
Nextcloud version 3.6.2git
Git revision 2a703f2
Using Qt 5.15.7, built against Qt 5.15.7
Using Qt platform plugin 'wayland'
Using 'OpenSSL 3.0.7 1 Nov 2022'
Running on Arch Linux, x86_64
I noticed Nextcloud saves 2 entries to my secret service provider
(KeepassXC) although I only connect to one server.
Whenever I restart nextcloud-client, keepass asks me whether I want to
allow it to access the secret service entry and whether to remember this
decision. This worked fine until about 2-3 weeks ago. Other apps using
keepassxc secret service still work fine.
I then tried deleting one of the two nextcloud entries (the first one, did
not work if I deleted the second one) in the secret service, started
nextcloud and it used the remaining entry without requiring confirmation.
But it readded a second entry after which the next restart required
authentication again. If I deleted that most recent added entry the next
restart worked fine again and so on.
So I assume there is an issue with the two entries being created by
nextcloud.
—
Reply to this email directly, view it on GitHub
<#4715 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANUKZSVN4GAOKUBB4YAQQLWHZZE3ANCNFSM53EJTB3A>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I was not able to find the issue you mentioned but opened a new one on the keepaasxc github. |
|
I can confirm that the issue is fixed in Linux appimage 3.6.2 |
|
I'm on 3.6.2, appimage on Debian unstable and the issue persists. I have to grant authorization everytime I open the app. |
|
On appimage 3.6.4 problem Is resolve |
|
AppImage 3.6.4, Kubuntu 22.10, problem not solved. |
|
Any KDE user still experiencing the issue ? See: #2573 (comment) |
and others
Bug description
after configuring the installation URL and accessing the synchronized folders at the next restart, nextcloud always starts Chrome to always request authorization to access the site as occurs in the configuration step
Steps to reproduce
...
Expected behavior
When clicking on the share dialog, share by e-mail should be an option.
...
Which files are affected by this bug
All
Operating system
Linux
Which version of the operating system you are running.
Ubuntu 22.04
Package
Appimage
Nextcloud Server version
24.0.2
Nextcloud Desktop Client version
3.5.2
Is this bug present after an update or on a fresh install?
Fresh desktop client install
Are you using the Nextcloud Server Encryption module?
Encryption is Enabled
Are you using an external user-backend?
Nextcloud Server logs
after configuring the installation URL and accessing the synchronized folders at the next restart, nextcloud always starts Chrome to always request authorization to access the site as occurs in the configuration stepAdditional info
No response
The text was updated successfully, but these errors were encountered: