Nextcloud update to breaks Nextcloud on 32 bit systems

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face: is for home/non-enterprise users. If you’re running a business, paid support can be accessed via where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:


Or for longer, use three backticks above and below the code snippet:


Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5):
Operating system and version (eg, Ubuntu 20.04): Raspberry Pi OS
Apache or nginx version (eg, Apache 2.4.25): nginx 1.14.2
PHP version (eg, 7.4): 8.2

The issue you are facing:
Updated from to This broke my whole NC installation. Already spent 3 hours trying to fix it.

Is this the first time you’ve seen this error? (Y/N): Y :warning:

Steps to replicate it:

  1. Run on a 32 bit OS
  2. Update to NC

The output of your Nextcloud log in Admin > Logging:

Irrelevant, SEE

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

Irrelevant, SEE

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

Irrelevant, SEE

Output errors in nextcloud.log in /var/www/ or as admin user in top right menu, filtering for errors. Use a pastebin service if necessary.

Irrelevant, SEE

How can you release a STABLE (!!!) update which kills NC instances?

I’m so damn annoyed… only looking for a quick solution to fix this ASAP!

Hopefully there’s a quick solution. Because restoring following Restoring backup — Nextcloud latest Administration Manual latest documentation is quite complicated and I never had to do this before, even I got

  • nextcloud directory including theme and config directories backup 2 days before update incident
  • data dir backup 2 days before update incident (of course I also have the current files)
  • database backup 7 hours before update incident → it does not match the nextcloud and data dir backup time.

Restore attempt would be:

  1. just restore nextcloud files from latest $nextcloud-data-dir/updater-ocXXXXXXXXXX/backups/

1. restore database to latest snapshot
2. restore program files (/nextcloud/ including config and themes and many other folders like core and apps etc.).
3. Can I keep the current data directory and sync the database with it using the occ files:scan --all afterwards?


(hopefully) solved by “downgrading” to (without database or data directory) by

  • restoring $nextcloud-data-dir/updater-ocXXXXXXXXXX/backups/nextcloud- over my /var/www/nextcloud
  • and running occ upgrade afterwards.

Many double checks, backups and tests before and after that included made this freaking update steal me 5 and a half hours of my life time (instead of the usual 10 minutes for minor updates), making this the worst update experience EVER.

Because of this personal experience with a stable (!!!) release AND the fact that

… I currently can’t trust Nextcloud('s update mechanisms) anymore. I don’t hope but expect others to run into this very same issue once the or 28.0.2 update is performed by other 32 bit users. Have fun with that.

I’ll check back in a few weeks once [Bug]: Composer dependencies require a 64-bit build of PHP · Issue #43157 · nextcloud/server · GitHub is hopefully confirmed to be fixed in the 27 channel.

I have no issues after updating to 27.1.6 on a 32bit Debian Bookwoorm:

I barely have any apps active though.
Do you have any special apps installed?

See [Bug]: Composer dependencies require a 64-bit build of PHP · Issue #43157 · nextcloud/server · GitHub to avoid redundant content.

Could be related to the issue I am seeing.
Did it look for you like on my screenshots?

My instance is currently totally broken…

No, a different issue. Your NC is basically working, at least on the basic PHP level. In my case it wasn’t operational at all - not even a login screen presented, not serving requests via WebDAV, CalDAV etc.


For anyone finding this thread, please check the issue[1] for the current status.

Quick summary:

  • we are doing 32-bit tests (and have been)
  • this problem only occurs if the app suspicious_login is enabled (it is not by default)
  • fix is easy if you find yourself in this situation: disable the suspicious_login app from the command-line (see the issue for command examples to do this) or before upgrading Server
  • breakage occurs due to a mixture of a third-party tool (Composer) enforcing a config parameter we already had in place that should have prevented this app from functioning on 32-bit environments already (apparently this wasn’t the case due to a bug in that tool that was recently fixed which is where the error message reported here is coming from) + we could have had another layer of prevention in-place in that app to prevent it outright from even being activated in 32-bit environments
  • if you’re using IPv6 at all, the suspicious_login app probably would have already been broken in odd ways in 32-bit environments, though it may or may not have been noticeable
  • we’ll likely add that second layer of prevention which will more cleanly prevent this app from even being enabled in 32-bit environments going forward


So from a user‘s perspective: either update NC or use the suspicious_login app.

We can’t have both.

And yes, 32 bit server and no IPv6 is exactly my use-case, the app is doing great for a long time.

From time to time it seems apps (still) have the power to knock out server completely. Rather inacceptible, isn’t it? :frowning:

Maybe we can reference the issue from the app repo to see and track if they can resolve this dependency? So users can decide on their own (wait, update, …).

Target: update NC server AND continue use of suspicious_login app.

Any update?

According to [Bug]: suspicious_login app dependencies require a 64-bit build of PHP · Issue #43157 · nextcloud/server · GitHub the issue should be fixed fixed it.

1 Like

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.