Can Not Log In - And problems with update - **Update – issue resolved**

ℹ️ Support
1

Have read and understood How To: Get Help on Shared Webhosting

PHP 8:3

Have had Nextcloud (NC) with Orderland.se since July 2019 and except for a few update occasions, the update function complained and stopped on a error.log that you had to share.

Latest working version NC 33.0.2. So the update to 33.0.3 came and I start as usual the update starts via the function in the administrator function, but it stopped after the backup part with the following error message:

Step 3 is currently in process. Please reload this page later or remove the following file to start from scratch: /home/xxx/nextcloud/updater-oc6vo5f4mnwk/.step

Nextcloud_2026-06-03 14 58 36
Nextcloud_2026-06-03 14 58 361312×854 15.8 KB

NC continued to work without problems so I thought I would wait until the next update version. The same error also occurred with version 33.0.4. When the same error also occurred with version 33.0.5, I contacted Oderland support, who later came back with a probable error that their server log indicated was too small memory_limit. So I increase it from 256 to 512.

Then the installation went all the way down and when you press on there, as far as I remember, the installation goes to another page where installation should continue. That page ‘Blixtaded’ and only the following text was displayed:

Internal Server Error

The server encountered an internal error and was unable to complete your request.

Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.

More details can be found in the server log.

Note that this text appeared on the page (url) https://files.xxx.se/index.php/login/challenge/totp

I have also used the TOTP plugin for a long time and it has been updated. Oderland support now has the case and I hope they find some information in their server log.

Tried restoring using backups, going as far back as May 10th. Mej every time the authentication tool TOTP comes up, the previously displayed text ‘Internal Server Error’ is displayed

Can mention that now Softaculous shows that installed version of NC should be 33.0.5, Haven’t used Softaculous for several years so there are no backups! Gets the feeling that it could be TOTP causing it.

And NC still work. I see that the other features, DavX and Nextcloud for Windows are working.

Is there any way to turn off TOTP via phpMyAdmin and some part of the database, or any other tips that can be used to able to log in?

Would one via Softaculous dare to run an installation via them again in the same place and the same database name?

Chris.

2

In addition to the web server logs, the two logs to check are part of your Nextcloud installation:

  • data/nextcloud.log
  • data/updater.log
3

This is not resolved yet!

Because I am convinced that the error which means that I cannot log in is with the TOTP authentication app.

I wonder if you can go the back way, so to speak, via the files on the server or via the database and turn off the function there, to be able to log in?

4

Now when I try to update to 34.0.2 I get the following message ‘Update completed with warnings. Check the details for more information.’ In show details, after a red ring with a red x in it, InvalidArgumentException: Index name ‘id’ for table ‘oc_schedulingobjects’ collides with the constraint on table ‘oc_dav_shares’.
When you then do as the update function says Continue to Nextcloud, the update just starts over. Is in a loop!

One more question, since it always seems to be the authentication tool TOTP, which caused the problem with the update in the beginning, is it possible to remove this function via the database?

Tips on how to proceed wanted!

5

For recent updates to fix things, it is good to have access to occ via command line where you can as well disable apps. You could also just delete the code in the apps/-folder, however for a core app, I don’t know if that is a good idea.

Looking at the oc_appconfig table with a setting enable on/off. Not sure if that would be enough or for enabling/disabling there is much more to happen.

If you have access to data and database, you could migrate the whole setup into a virtual machine, do the upgrade properly, then migrate back. Then at least you have no performance limitations. But of course that is very difficult, and running on shared hosting in the first place is probably to have it as easy as possible.
Hacking manually things in the database, if you don’t know more details there is a high risk of breaking something at some time. And without terminal access, your ways of debugging and analyzing problems is more limited.

If you are hitting more and more limits, at some time I’d consider moving to a more suitable platform (either managed Nextcloud solution, or at least some virtual private server).

6

It would be helpful if you filled out the actual support template rather than ignoring it.

We can’t help you beyond guessing since we have incomplete details.

7

Update – issue resolved

The problem has now been resolved.

The Nextcloud installation itself and the database were healthy, but the configuration contained Redis/memcache settings that were not usable in this shared hosting environment. This caused problems with transactional file locking and generated errors/warnings.

The Redis-related configuration was removed and Nextcloud was allowed to fall back to database-based transactional file locking. After cleaning the configuration and checking the installation, Nextcloud 34.0.2 is working normally again. Files, contacts/calendar synchronization and access from Thunderbird have been tested successfully.

The only remaining setup notice is:

“The database is used for transactional file locking. To enhance performance, please configure memcache, if available.”

This is expected because Redis is not available/configured on the hosting account.

There was also a large amount of old data in the Nextcloud trash bin and an old updater backup. Cleaning these reduced the Nextcloud data directory from approximately 9.4 GB to 5.0 GB.

I cannot say with certainty what originally introduced the incorrect Redis/memcache configuration. One possibility is that it remained from an earlier configuration or upgrade.

Thanks to everyone who looked at the problem.