I’ve installed Nextcloud in early December 2020 and set it up for a collaborative project.
I tested it with another user and things have been running smoothly.
The installation is on a Strato.de PowerWeb Basic webspace.
I’ve checked the forum and had seen other users confirming that this is possible.
Beginning 2021 I’ve added some more users that I was going to invite.
Two days later January 6th, I can barely log into the cloud.
Things I’ve done so far:
– Changing PHP version to 7.2, 7.3 and back to 7.4 / enable and disable PHP Boost.
– Reverting the Nextcloud folder and MySQL database back to mid December via Backups.
– Reaching out to Strato support, to make sure they are not blocking the cloud on purpose.
(the support person suspected a change in the PHP version)
– Deleting Nextcloud and the database. Setting it all up new in another location with entirely new database.
-> Again testing different PHP versions and PHP Boost.
This is the error I’ve kept getting before all the testing:
If this happens again, please send the technical details below to the server
administrator.
More details can be found in the server log.
Technical details
Remote Address: 1XX.1XX.9X.2XX
Request ID: X-chpRrsxlG8uBGC@8ZXVgAAAQ8
Nextcloud seemed the perfect solution for this collaboration.
But if I can’t rely that it keeps working, once set up, I will have to look for something else.
Well it would be interesting to know what is wrong there. Some webhosting providers have limits on the database connections, you could run out of memory, …
I would use webhosting packages only for very small setups with one user (or extremely few). If it is just for a few files the calendar etc. For more users, a considerable amount of users that access at the same time, possibly with several devices, I’d rather use a more controllable environment, vservers, dedicated servers or if it has to be cheap something hosted at home on own hardware. Some already have fibre access at home.
Webhosting packages are different. Perhaps you can find some experience among other customers of your provider up to which level they manage to run Nextcloud properly.
Dear Szaimen, I’ve seen the posters about Collabora in the forum before.
But after looking into Collabora, and figuring that I won’t be able to host it on a Strato webspace, I’ve already disabled it begin December.
Dear tflidd, thanks for your fast response.
Since I’ve set up a brand new Nextcould inside a different folder on my webspace with only one user and also with a brand new MySQL database, I think there must been made a change to the servers configuration alongside of installing PHP 8 (it is a new option, that I had not seen before in the control panel). Also the answer of the support person at Strato points to this.
(I did share the Error message above with the support team.)
Regarding the performance:
The collaboration is a lose non-profit side-project that won’t need a lot of performance, but the idea of having one central place to communicate and share links and documents, rather than setting up a bunch of different channels and accounts on different platforms appealed to me.
attack?
There is one last suspicion. A contacts mailbox had been hacket, that contained a link to the clouds address. This might have sparked interest of a hacker, that now is trying to get in. But the support team of Strato should have seen such an ongoing attack, when looking into this. Edit: I’ve just changed the URL pointing to the Nextcloud to another vacant domain name. Things are smooth and steady. Hope I’ll be able to change back at one point, once this idiot has lost interest.
I’ve been monitoring Logs and can’t find any suspicious activities.
Now I’ve added another trusted domain to the config.php and while I am able to reach the nextcloud wit this alternate URL and navigate within the files. The login-page gives me this error, when I reach it through the desired .cloud domain.
There were too many requests from your network. Retry later or contact your administrator if this is an error.
Is it possible, that .cloud domain are routed differently and are generating too many redirects?
This started once I’ve been forcing SSL with a 301 redirect. I’ve disabled this several times since then, without success.
you could try to remove excessive authtoken from database to see if this resolved your issue of slow login in web interface/DAV/desktop client time out error
Go to your database’s interface, then issue following command:
delete from oc_authtoken where login_name = ‘YOUR_LOGIN_NAME’;
And you sould see the slow login issue solved immediatly! You need to run this command from time to time since the invalid auth token will increase ovetime…
Hope I’ll be able to change back at one point, once this idiot has lost interest.