11.0.2 incredibly slow login

ℹ️ Support
,
1

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

Can you reliably replicate it? (If so, please outline steps):

Yes, at any point by logging out and attempting to log in again.

The issue you are facing:

I upgraded to 11.0.2 earlier, lovely upgrade, nothing went wrong and the logs are clean.

However, logging in from a logged out state takes upwards of 40 seconds. It is insanely slow.
Once logged in everything is fine, maybe not quite as snappy but no noticeable difference to 11.0.1.

Due to this delay, my mobile clients can’t login or upload to the server.

The output of your Nextcloud log in Admin > Logging:

Here’s what the mobile clients appear to be doing:

Info	admin_audit	Login successful: "jason"	2017-02-28T00:14:40+0000
Info	admin_audit	Login attempt: "jason"	2017-02-28T00:14:40+0000
Info	admin_audit	Logout occurred	2017-02-28T00:14:06+0000
Info	admin_audit	Login successful: "jason"	2017-02-28T00:13:12+0000
Info	admin_audit	Login attempt: "jason"	2017-02-28T00:13:12+0000
Info	admin_audit	Login successful: "jason"	2017-02-28T00:12:43+0000
Info	admin_audit	Login attempt: "jason"	2017-02-28T00:12:43+0000
Info	admin_audit	Login successful: "jason"	2017-02-28T00:09:38+0000
Info	admin_audit	Login attempt: "jason"	2017-02-28T00:09:38+0000
Info	admin_audit	Login successful: "jason"	2017-02-28T00:06:54+0000
Info	admin_audit	Login attempt: "jason"	2017-02-28T00:06:53+0000
Info	admin_audit	Login successful: "jason"	2017-02-28T00:06:51+0000

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

N/A

The output of your Apache/nginx/system log in /var/log/____:

I’ve inspected both Apache and MariaDB logs for errors, absolutely clean as a whistle. Nothing to indicate an issue whatsoever.

2
3

I have:

  • Rebooted Nextcloud
  • Rebooted the MariaDB host server
  • Rebooted the proxy (same behaviour with proxy or with direct nc server ip)
  • Added ‘auth.bruteforce.protection.enabled’ => false, to the config
  • Inspected the logs for errors (there are none)
  • Kept Chrome dev tools opened while trying to load the page (I see HTTP 303 see other on page load)

No improvement as yet.

4

2 factor authentication? Sometimes it can help to check the processes to find out where it hangs. Or run your webserver in debug mode, then you can perhaps see why it is hanging or what it is waiting for.

5

No 2 factor enabled and I’ve added no new plugins between 11.0.1 and 11.0.2.
I’ll start with htop and see if anything does indeed hang, then move to verbose logging.

6

I’ve had htop running on all nodes in the chain (proxy, webserver, database server) - nothing, absolutely nothing is reporting anything of significance there. Loads are minuscule and the apache/mysql processes barely register 5% on the host while logging in.

I’ve enabled more granular logging, I don’t have the knowledge needed to figure out gcc debugging, but from what I’ve increased there’s still no meaningful data - error logs are clear, access logs look normal (no errors).

This is bizarre.

7

So do don’t recommend to upgrade right now, did you?

8

I guess only others who have an infrastructure similar to mine? Until we know root cause is not my network (either I fix it or someone else gets this issue) then no, I wouldn’t advise against it.

image.png765×442 19.7 KB

What I would say is take a snapshot to roll back to.

9

Right.

So now everything is fine.

I did a couple more service restarts on Apache while toggling the bruteforce config entry on and off and now it logs in once again in about 1sec.

Who manages the bruteforce app? If it activates against a user/IP does it have a set timeout? @MorrisJobke @rullzer @nickvergessen

10

There is no real brute force app, but it is baked into the servers core components. The brute force list is valid for 24h if I remind this correctly (cc @lukasreschke). As you use a proxy it’s very likely that you don’t have it setup correctly. The X-Forward-For HTTP header needs to be set so that the Nextcloud instance sees the correct IP address of the different users and not only the one of the proxy. If this is not the case all users will get a penalty once a single user used a wrong password, because only the proxy IP is seen by the nextcloud and everybody has the same IP.

11

That’s exactly as I have proxying set up at home because a) it requires no additional config and b) I’m the only user :slight_smile:

That makes me wonder why it would registered a wrong password if that did indeed happen. There are no failed login attempts.

Any other reason it would kick in?

12

@lukasreschke implemented it :see_no_evil:So he can answer this :wink:

1 Like
13

At the moment this is the only place where it is used.

1 Like
14

Also a report here on github:

1 Like
15

Same problem . Taking too much time to login after clicking login button

Rebooted web server (sudo service apache2 restart)
Added ‘auth.bruteforce.protection.enabled’ => false, to the config

But it is not fixed

16

Hello,

I can confirm the same problem in a fresh installation using Samba AD as user store. Problem for both AD users and local (nextcloud) users. Zabbix monitoring show a login time of around 16~18 seconds. Server is also behind a proxy. I have tried the solution: auth.bruteforce.protection.enabled’ => false , but did not work.

Thank you.

17

Anyone else facing this type of problem, please update the issue:

18

Just solved the problem.

While the brute force protection was activated, the MySQL table “oc_bruteforce_attempts” has filled with my username, triggering the bruteforce protection when I tried to login.

After disabling bruteforce protection, I still encountered the problem. Rebooted my NC server: still same problem. I could not reboot my MySQL server, it is a production machine. However, I issued the following mysql statement:

“DELETE FROM oc_bruteforce_attempts”

SHAZAM! Now the login is quick, and the table is not filling up again.

The bruteforce protection needs more intelligence. Like when a user / IP succeeds, clear the info from the table. I disabled it for the moment. When it gets good enough, I will reactivate it. For the moment, just using strong passwords should do the trick. And other protection in frnt of the web server.

Have a good one!

2 Likes
19

Resolved !
Many thanks, i disabled this bruteforce feature.
Is there pull requests to fix this ?

I am using beta version 12 :’(

20

we have same issue with a very similar architecture to original poster. Will try x-forward-for setting as first step (will help track other issues on client servers anyway, been on the todo list for… )