Starting today, user not able to login with the windows desktop client

Nextcloud version (eg, 10.0.2): 12.0.0
Operating system and version (eg, Ubuntu 16.04): Ubuntu 16.04
Apache or nginx version (eg, Apache 2.4.25): Apache
PHP version (eg, 5.6): 7.0.18
Is this the first time you’ve seen this error?: Yes

Can you reliably replicate it? (If so, please outline steps):
Login to desktop client. Get error message: “No connection to nextcloud at Operation cancelled.”

The issue you are facing:
Starting today, this one user cannot login to the desktop client. We have reinstalled the client, rebooted her machine, rebooted the cloud server. Nothing helps at all. After 3 attempts her account gets locked by the domain. This is using LDAP. She can login to the web page for the cloud server with no problem, using the same credentials and that works. She has been working for 7 months with zero problems, until today. She uses the desktop client daily.

The output of your Nextcloud log in Admin > Logging:

{“reqId”:“vualWAzpK1RBCUXh1NfL”,“level”:2,“time”:“2017-07-03T21:07:02-04:00”,“remoteAddr”:“2001:470:8f63:1::…”,“user”:“5711E085-1756-4CDF-B821-8AD7CE00205D”,“app”:“no app in context”,“method”:“PROPFIND”,“url”:"/remote.php/webdav/",“m
essage”:“Missing expected parameters in change user hook”,“userAgent”:“Mozilla/5.0 (Windows) mirall/2.3.1 (build 8) (Nextcloud)”,“version”:“”}

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php $CONFIG = array ( 'updatechecker' => false, 'instanceid' => '...', 'passwordsalt' => '...', 'secret' => '...', 'trusted_domains' => array ( 0 => 'cloud.dmz.aquila.local', 1 => '', ), 'datadirectory' => '/var/data/cloud/filesystem', 'overwrite.cli.url' => '', 'htaccess.RewriteBase' => '/', 'dbtype' => 'mysql', 'version' => '', 'dbname' => 'nextcloud', 'dbhost' => 'localhost', 'dbport' => '', 'dbtableprefix' => 'oc_', 'dbuser' => 'nextcloud', 'dbpassword' => '...', 'logtimezone' => 'America/New_York', 'log_rotate_size' => 10485760, 'loglevel' => 1, 'installed' => true, 'ldapIgnoreNamingRules' => false, 'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory', 'mail_smtpmode' => 'smtp', 'mail_from_address' => 'no-reply', 'mail_domain' => '', 'mail_smtphost' => '....aquila.local', 'mail_smtpport' => '25', 'mail_smtpname' => '', 'mail_smtppassword' => '', 'trashbin_retention_obligation' => '30, 60', 'updater.server.url' => '', 'maintenance' => false, '' => 'stable', 'versions_retention_obligation' => 'auto', 'trusted_proxies' => array ( 0 => '', ), 'theme' => '', ); The output of your Apache/nginx/system log in `/var/log/____`: - … [03/Jul/2017:21:26:47 -0400] "PROPFIND /remote.php/webdav/ HTTP/1.1" 207 1249 "-" "Mozilla/5.0 (Windows) mirall/2.3.1 (build 8) (Nextcloud)" - … [03/Jul/2017:21:27:19 -0400] "GET /status.php HTTP/1.1" 200 4939 "-" "Mozilla/5.0 (Windows) mirall/2.3.1 (build 8) (Nextcloud)"

There is a bug report with this error:

Can you user still login via web-interface?

The problem is not the “missing expected parameters” Every user gets that.
The problem is that she cannot login to the desktop client AT ALL. She has been using it for 7 months with no problem until yesterday.

Yes, she can login to the web interface.

This is a critical problem because she was using it daily.

Sorry, I didn’t find more references to this error.

Did you try to connect with a client from a different machine? Does native webdav work (WinSCP, Cyberduck)? Anything changed since you logged in (any update on client or server)?

@rullzer @mario any ideas what could be wrong and how the user can debug this problem further?

(background: there is no independent NC client, so such issues should go to the original bug tracker from owncloud, NC only provides its own theme). You could though report the no app in context error on the server-bugtracker:, currently I don’t know if it is a client-, server- or network-related problem.

I didn’t try those things, but I just found out something a few minutes ago.
I switched LDAP to the backup server, and it immediately started working.

This makes no sense to me though because my other 10 users have no problem…
Still investigating.

It appears that by clearing the LDAP cache (when I switched to the backup), that might have fixed the problem. I have now switched back to the primary LDAP and it is still working for 4 hours now.