SOLVED: User dependent timeout on website login

I seem to have wrecked up something on my pretty fresh install of NC26 beta 3.

When logging in to the web frontend as user, i enter my username (“tim”) and my password which is correct. The website tries to log me in, but fails because of “gateway timeout” after roughly one minute.

The same website logs me in fine when i use my admin account within a few seconds.

The server is running beautifully, other domains on the same machine load in fractions of a second.
The only thing logged in apache logs reads:
[proxy_fcgi:error] [pid 6321] (70007)The timeout specified has expired: [client :] AH01075: Error dispatching request to : (polling)

Things i have done to track this down:
Restart apache2
Restart php8.2-fpm
Restart the web server altogether
Try different clients / browsers
Try IPv4 vs. IPv6
Disable RewriteRules

The main difference between my user account and my admin account is that my user account has a few gigabytes of test data, calendar & contacts data. the admin account is used solely for administration.
The website was installed with NC26 beta 2 and updated a few days ago. It ran wonderfully until 2 days ago. Since then i was only testing a little RewriteRule settings in order to make iOS clients find caldav/carddav interfaces which still works fine.
I am willing and mostly able to trace this down myself, but could do with a hint in a direction i’m not looking at right now. What might make one user fail to login and the other one succeed?
Details follow,
Thanks for reading and thinking,



  • Debian GNU/Linux bookworm (wanted to get rid of PHP7 when reinstalling)
  • Apache 2.4.54 with all mods required for nextcloud (and Joomla4)
  • MariaDB
  • PHP8.2
  • 100MBit connection inside hosting provider
  • IPv4 and IPv6 work well otherwise
  • LogLevel in apache: notice


  • Debian GNU/Linux with NC client from Debian/stable
  • Android and iOS devices

Can you check if the failing user has a high amount of auth tokens ?
Similar report Third beta of Nextcloud 26 - #12 by mr_mr

It certainly has. I don’t see this in the admin panel, but remember this from the last times i could look into the user account. Some old tokens were marked for removal, but never seemed to disappear.
I found an article about removing auth tokens in mysql interface, but i haven’t tried that yet.
Thanks so far,

Lo and behold, i could just login to my user account…
Some auth tokens are still marked for remote deletion, but that never happens!

Deleting ALL the auth tokens solved my issue. Thanks for caring! I’ll hopefully mark this as solved.


When it’s marked for remote removal that means there needs to be an client to actually get erased (like the desktop client). But in this case that’s probably not what you want, you want want to revoke the tokens, removing them immediately.

Ah, ok! That clears it up. Thanks!

This bug really has been here for ages…

Repetition, a basic principe of learning!

Or quite something different in this case.

Well, yes and no. If everything worked on 25 but failed directly after upgrading to 26 Beta, something changed …
(At least in the beta thread it was an upgrade. But yea, came across this multiple times as well)