Nextcloud does not open login link anymore

[niklasbuechner]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Expected behaviour

Both the "Reopen Browser" and the "Copy Link" button should work.

Actual behaviour

Both the "Reopen Browser" and the "Copy Link" button don't do anything anymore.

This is on macOS Big Sur 11.15.1 and I just updated the Nextcloud macOS Client. However, since it does not show you a version, if you are not logged in, I don't know what version I am on 🤷 .

Steps to reproduce

1. Install the macos client
2. Try to log in.
3. No button works

Client configuration

Client version: It says 3.3.1 on the website but I can't verify that.

Operating system: macOS

OS language: English

Qt version used by client package (Linux only, see also Settings dialog):

Client package (From Nextcloud or distro) (Linux only):

Installation path of client: The path the standard installer uses

Server configuration

Nextcloud version: 22.1.0

Storage backend (external storage): Postgres 👀

Logs

Please use Gist (https://gist.github.com/) or a similar code paster for longer logs.

1. Client logfile: Since 3.1: Under the "General" settings, you can click on "Create Debug Archive ..." to pick the location of where the desktop client will export the logs and the database to a zip file. On previous releases: Via the command line: nextcloud --logdebug --logwindow or nextcloud --logdebug --logfile log.txt (See also https://docs.nextcloud.com/desktop/3.0/troubleshooting.html#log-files)

2. Web server error log:

3. Server logfile: nextcloud log (data/nextcloud.log):

[niklasbuechner]

I just enabled logging on the desktop client and now the buttons work. 👀

Could it be that the buttons only work with logging enabled?

[FlexW]

How did you enable logging? Logging is enabled by default and there is no way to turn it off.

[niklasbuechner]

Oh, okay, then I did not fully understand the help text here. The checkbox was not checked. It only worked with the checkbox checked.

To open the window I followed the instructions on your troubleshooting page by using this command: /Applications/nextcloud.app/Contents/MacOS/nextcloud --logwindow

[FlexW]

@niklasbuechner Ah okay. Yes, that dialog is old and should be updated. Could you disable the logging again and see if the problem still persist or even better reinstall the client and see if you still have the same problem? If yes, please send us the logs. You can find the logs in $HOME/Library/Preferences/Nextcloud/logs

Could you also please tell me where you found the documentation to bring up this dialog?

[radoeka]

Same issue for me. I don't know about the logging, but I could not login :(

[FlexW]

@radoeka Could you please share your logs https://cloud.nextcloud.com/s/6w5abTCtdHJQjrw

[radoeka]

@FlexW I went back to version 3.2.4 With that one it works. Next try is 3.3.0. For me it did not work with 3.3.1

Like @niklasbuechner I was presented the window about the logfile. Also that it persist between client restarts. That's what I don't want. As such I did not enable the logging (I don't how to disable the logging, or whether that is possible at all).

I expect a verbose mode, from which I can see the output or redirect it to a file.

[radoeka]

With 3.3.0 I can login without problems. With 3.3.1 I can't login.

If someone can tell me how to switch off logging, I can try to collect logs.

[radoeka]

@FlexW this was helpfull https://docs.nextcloud.com/desktop/3.0/troubleshooting.html#log-files It seems that I've logs enable already, without knowing. I uploaded some logging. A part of the 3.3.0 logging and similar parts of the 3.3.1 logging. You'll notice that there are 2 users mentioned, as I've 2 users active in that client. Unfortunately it is not possible to instruct the client to start with which client. That makes it all the difficult to login.

Anyway I hope the logging is useful.

[FlexW]

@radoeka thanks. Did you upload masked-log-3.3.1 ? Did you remove/replaced something in the logs (for example the server url)? If you don't want to talk about it in public please email me at felix.weilbach@nextcloud.com .

[radoeka]

@FlexW I retrieved the related patches (for this issue) that went into version 3.3.0.

The first patch that was applied at 6 August, breaks nextcloud-desktop for me. After this patch I can no longer login.

commit 6a414d5fb38f44a9cc692238663215447d974e35
Date:   Fri Aug 6 11:34:49 2021 +0200

    Ensure that the users id is used for accessing webdav

When I apply this patch 20210808.patch.gz on top of 3.3.0 it stops working.

When I leave this patch out of the (package) build and try to build with the other 2 related patches, the (package) build fails as the first one must be present for the other patches.

The command I used to get the diff:

git diff 694c6e721415a79b127855c9576fc54cf57b54f0 6a414d5fb38f44a9cc692238663215447d974e35

[FlexW]

@radoeka The problem is that

commit 6a414d5fb38f44a9cc692238663215447d974e35
Date:   Fri Aug 6 11:34:49 2021 +0200

    Ensure that the users id is used for accessing webdav

Broke it for people that use LDAP. If you use LDAP it's expected that this patch breaks it for you (Do you use LDAP?). The following patches just fix the regressions that this commit introduced.

Could you send me in private your nextcloud.cfg? I want to see to which values dav_user and webflow_user are set.

[misternerd]

@FlexW I think I'm affected by this bug as well, though my symptoms are slightly different. I can copy the link for the browser and run through the auth flow (login, approve client). However, after I confirm the login, the client doesn't recognize it the flow been completed. There's a countdown from 30(?) and then the modal just stays open indefinitely (waited for ~10 minutes)

• PPA Client 3.3.1-20210814.134354.cd934ba80-1.0~focal1 => doesn't work
• PPA Client Alpha 3.3.50-20210817.111523.d241c21c2-1.0~focal1 => doesn't work
• PPA Client Beta => 3.3.0-20210722.074205.2e07e93a4-1.0~focal1 => works

The client is connected to two servers, both v22.1.0 and all apps up to date. As a sidenote, the client is running in a Docker container based on Ubuntu 20.04. I'll mail you my config.

[radoeka]

For me it is similar to @misternerd

I can copy the link for the browser and run through the auth flow (login, approve client).

me too.

However, after I confirm the login,

me too

the client doesn't recognize it the flow been completed.

Indeed.

There's a countdown from 30(?)

similar for me. ****

and then the modal just stays open indefinitely (waited for ~10 minutes)

I think it is the same for me.

*** With 3.3.0 (and prior) normally when the countdown reaches '0', the window disappears and the client is logged in.

[trev0r-STA]

Same thing here on Linux with the AppImage. Nextcloud server 21.0.4 on Debian 10.10. All is up to date Back to 3.3.0 AppImage. Works again If you need more info, feel free to ask

Regards

[radoeka]

Just wondering, would it perhaps help to delete the login at 3.3.0, update to 3.3.1 and create the login again? Perhaps there is some caching, cookie, or configuration that must be removed or recreated? I may have a look at this over the weekend.

I've 3.3.1 working with windows, but it does not work at a Linux system. The Linux system has actually 2 logins configured, is that maybe an issue?

[trev0r-STA]

Just test it. Remove the account from Nextcloud 3.3.0. Start 3.3.1, add account, all works great. Stop the client, restart it, connection failed And if I start the client with the command line, I've the following error message: Remote error from secret service: org.freedesktop.Secret.Error.IsLocked: Cannot create an item in a locked collection Don't know what to think

[andreacatta]

Same as @misternerd for me (NC 20.0.12, mac client 3.3.1)

[FlexW]

After checking logs it seems like there are different issues, but I think they all boil down to that the entry in the keychain can not be found. That is because 3.3.0 put the dav user in places where the webflow user was expected. People that might be getting problems are people that have a different username for webflow login and for dav and had installed the 3.3.0 version (or some daily). Other people should not be affected.

I think one of the following should solve it for everyone:

• Go to your configuration file nextcloud.cfg and set dav_user to your dav user and set webflow_user to your name that you use to login into Nextcloud. For some people that might be for example the email address.
• If that does not work you should delete your Account in the Nextcloud client and recreate it in 3.3.1.

I'm sorry for the regression, but I'm not sure we can roll out a patch for this problem as there is logic in the desktop client that detects non-matching login names and I don't want to break it.

If you are still having problems after you deleted your account and recreated it with 3.3.1 then please open a different issue, because then it is a new problem and we want to keep the issues focused.

@15bart15 Could you share your logs with your GitHub username here https://cloud.nextcloud.com/s/6w5abTCtdHJQjrw

[radoeka]

@FlexW how can we determine the values for dav_user and webflow_user that should get configured with 3.3.1? The webflow_user seems trivial, but what about the dav_user?

[trev0r-STA]

@FlexW Which logs do you want ? The server log ?

[FlexW]

@radoeka dav_user is normally your nickname that you used to create the account and NOT your email address. If you are using LDAP with Active directory then it's probably your Active Directory id.

@15bart15 The logs of the desktop client. You can create them when you go to Settings -> General -> Create debug archive...

[trev0r-STA]

@FlexW Done

[FlexW]

@15bart15 thanks. From looking at your logs it looks like the client can not store the password of your account because your keyring is locked. Could you make sure that is unlocked? Are you facing the same troubles with older versions of the desktop client?

[radoeka]

dav_user is normally your nickname that you used to create the account and NOT your email address. If you are using LDAP with Active directory then it's probably your Active Directory id.

@FlexW : I don't use LDAP. I don't use my email address as webflow_user, or as dav_user (at least not that I'm aware of). If I'm not mistaken they're just the same (but you can verify this in the config that I provided to you). When I look in my nextcloud log for lines with dav or DAV the user is just my login name. To prevent any confusion, is it possible to look up the webflow_user and the dav_user that are used with version 3.3.0, in for example the nextcloud logfile?

3.3.1 works for me at windows. Where is the configuration file stored at windows? Does it make sense to review the nextcloud-desktop configuration file at windows? What is the difference for the nextcloud-desktop client at windows and linux?

Where is the keychain located at Linux?

Does it make sense to remove the cookies in ~/.config/Nextcloud? What impact does it have when the cookie files are removed?

[romkazor]

after update on 3.3.1 (windows 10 x64) and logout then login dont work, confirm problem. downgrade to 3.3.0 solved problem but its temporary solution.

[mgallien]

I could reproduce a scenario where login is no longer possible with an already setup account and data is removed from keychain. https://github.com/nextcloud/desktop/issues/3694 I would highly suggest that we separate the different issues in different tickets. This is needed to be able to identify the different scenario to reproduce the errors and fix them.

[mgallien]

@radoeka

Where is the keychain located at Linux?

It depends on your desktop workspace. Usually that could be KWalletManager or Gnome Secret

I usually access them via their graphical interface and do not know much about their internals

[radoeka]

As I run the client on an "small" (not so powerful) system, I use fvwm as window manager. No KDE nor Gnome, I think that there is no keychain application around (automatically). For KDE this would kwalletd (I assume) it's not running, no process with secret either.

[FlexW]

@radoeka If you have no keychain then it is expected that you need to login every time the client starts (because the client can not store the password). Was that the same in the past?

[trev0r-STA]

@FlexW Don't know how to unlock my keyring. If I try my login password, Debian said me Wrong Password, if I try my nextcloud password, same thing. So before 3.3.1, I click Cancel several times and it 's ok 😕

[radoeka]

If you have no keychain then it is expected that you need to login every time the client starts (because the client can not store the password). Was that the same in the past?

Yes, that was the same in the past. No problems with that (expected) behavior. With 3.3.1 I just can't login. Is it possible to provide a patch, that adds debug code, so it will be easier to determine when, where or how the code fails?

[ogmueller]

I think one of the following should solve it for everyone:

• Go to your configuration file nextcloud.cfg and set dav_user to your dav user and set webflow_user to your name that you use to login into Nextcloud. For some people that might be for example the email address.
• If that does not work you should delete your Account in the Nextcloud client and recreate it in 3.3.1.

I am using a Mac, but both solutions don't work. The later one only works once. So if I delete the account and re-create it, Nextcloud syncs, but after a reboot all logins fail.

[radoeka]

Does someone how the new version 3.3.2 is with respect to this issue? Any improvement or no change at all?

[romkazor]

3.3.2 fix problem for me!

[radoeka]

Can a developer (@FlexW ?) confirm that 3.3.2 has a fix for this issue?

I spotted this change:

--- a/src/libsync/account.cpp
+++ b/src/libsync/account.cpp
@@ -84,7 +84,7 @@ Account::~Account() = default;

 QString Account::davPath() const
 {
-    return QLatin1String("/remote.php/dav/files/") + davUser() + QLatin1Char('/');
+    return davPathBase() + QLatin1Char('/') + davUser() + QLatin1Char('/');
 }

Does this make it work indeed?

[d235j]

No, that change does not fix this on 3.3.2.

@FlexW: I believe that 6a414d5fb38f44a9cc692238663215447d974e35 has a subtle bug in it. Both my dav_user and my webflow_user are identical and set correctly. The server just continues to return 404 no matter what (EDIT: this is not relevant, see below.). I am not using LDAP.

[d235j]

The cause of the issue is that the instantiation of a new WebFlowCredentials and the call to Account::setCredentials() at https://github.com/nextcloud/desktop/blob/02e518381cd852591ab5f47ece48bcaaf405988b/src/gui/wizard/flow2authwidget.cpp#L111

added in 6a414d5fb38f44a9cc692238663215447d974e35, causes the destruction of the original WebFlowCredentials object, breaking all its slots.

Specifically, Account::setCredentials() resets the credential, which destroys the original WebFlowCredentials object, at https://github.com/nextcloud/desktop/blob/02e518381cd852591ab5f47ece48bcaaf405988b/src/libsync/account.cpp#L182 .

All this breaks the urlCatched slot connection at https://github.com/nextcloud/desktop/blob/02e518381cd852591ab5f47ece48bcaaf405988b/src/gui/creds/webflowcredentials.cpp#L171

As the original WebFlowCredentials is destroyed, the above slot no longer exists. This prevents the urlCatched "auth completed" signal from ever making it any further, so the dialog box just stays up. This would also break any other slots in the original WebFlowCredentials.

The bug has absolutely nothing to do with the dav_user being different from the webflow_user. The authentication is succeeding — the signal just never makes it any further up the chain.

I am quite shocked that such a fundamental bug in the login flow made it into two general release versions.

[trev0r-STA]

3.3.2 does not fix the problem @d235j Maybe you're right. But it's too complicate for me 😂

[radoeka]

@d235j For some people it works for other it does not work. Is that possible?

What next to get this issue resolved, for the ones that suffer from it?

[d235j]

@radoeka If a user is already logged in, this issue won't happen until/unless that user logs out and then tries to log back in. Likewise I believe that use of a different authentication method might bypass this code, but I'm not sufficiently familiar with the codebase to say.

This is a specific issue with 3.3.1 and 3.3.2, and it would affect all users authenticating in this way. If a similar issue appears on other versions then it's probably not this.

What next to get this issue resolved, for the ones that suffer from it?

Downgrade to 3.3.0 or wait for 3.3.3. If you believe it is still happening in a version other than 3.3.1 or 3.3.2, please open a new issue.

[d235j]

I just tested #3727 and it does fix this issue.

[radoeka]

Can anyone that hit this bug, and have the recent released nextcloud-desktop installed (version 3.3.3) confirm that this version works OK. Thanks in Advance.

[radoeka]

I just made the jump, the last version (3.3.0) is working for me. Thanks for making it work again.