oh sorry, I must have expressed myself incorrectly. This is a storage-optimization feature that performs a defragmentation, so undoable… But i asked the hoster for help. Maybe they have another idea.
Just wanted to chime in that I have, since this morning, the same problem. When trying to access webmail/roundcube, I receive the timeouts described above.
A few observations:
The login page loads fine. It is only when trying to log in that I receive the timeout.
When using false credentials, I am being immediately returned to the login page, with an error. So the reason for the timeout seems to be AFTER successful auth
I massively increased the timeout. I copied the fastcgi_read_timeout line in the nginx config from the nextcloud section to the roundcube section. This increased the timeout from the default 60s to 630s. After this change, it was possible to log into roundcube, but the login process took much longer than 60s. Once logged in, all is fast and quick. (I know this is not a solution, because the nginx config will be regenerated. But it is a good data point).
So something is massively slowing down the login process. Unfortunately, neither the roundcube logs not the php-fpm logs nor the nginx logs are very helpful. I checked if there is a problem with DNS resolution, but there isn’t.
what i cannot explain: I have not touched the box in many days, yet the problem only manifested itself today. The logical conclusion should be that it is something external. That is why I checked the DNS resolution: If the login process queries a URL a couple of times, but now the DNS server is timing out, this would explain why suddenly everything takes order of magnitude longer. I found a related thread here in the forums where tweaking the /etc/hosts file was advised… it did not work in my case.
I started debugging roundcube, and so far, it looks like the carddav-plugin is causing the timeout.
I went to /usr/local/lib/roundcubemail/ and started debugging the index.php. The long delay occurs when roundcube is calling the login_after-hook. Not many plugins register such a hook, so I checked all of them.
I disabled the carddav-Plugin by running a chmod 000 plugins/carddav (!!! write down the permissions beforehand so that you can restore them, ls -l plugins is your friend), and booom, login is fast again.
So: There seems to be a problem accessing the MIAB-Nextcloud instance. This seems to cause the timeout.
ok, here is the rub. I re-enabled the plugin. Logged into roundcube. Went to contacts. Tried to add a contact to the address book ‘owncloud (Contacts)’. This worked, but it took like a minute for the PUT call to work. In address book ‘owncloud (Recently contacted)’, adding an entry failed. But it also took a minute or so to get the Error Message. I checked in my nextcloud, there is indeed no Contact group for the second address book. But this doesn’t really matter: even successfully adding an entry to the first address book takes way too long.
Thus, when logging into roundcube, the plugin carddav probably queries all nextcloud address books, and that is why it takes so long.
I have disabled the plugin for now (let’s see how many users will hate me for that), and will continue to investigate. But the error must lie with nextcloud, not roundcube. Keep you posted!
And since I got the attention of @JoshData: Thank you so much for MIAB. I cannot even enumerate the reasons I am grateful for it, there are so many. It is a great project, for its intentions and for its technical implementation.
well, great. I just sat down to continue to debug the problem, but it has vanished. Plugin carddav enabled, login is fast, creating new contacts through roundcube in the owncloud addressbook works immediately… I have reached the dreaded stage of ‘cannot reproduce’. I believe this is the end of the road.
Well, it was fun, if it occurs again, I will be back here.