Error 500 after upgrade from 32.0.0 to 32.0.1

ℹ️ Support
, ,
1
Support intro

Sorry to hear you’re facing problems. :slightly_frowning_face:

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

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:

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 32.0.1
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubunto 20.04.6
  • Web server and version (e.g, Apache 2.4.25):
    • 2.4.41
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • none
  • PHP version (e.g, 8.3):
    • 8.4.6
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • After upgrading from 32.0.0 to 32.0.1
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • NextCloud Updater
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • no

Summary of the issue you are facing:

I get HTTP Error 500 when browsing any page of my NextCloud instance.
In the updater, I have to replace the updater.secret every time again (but maybe that’s normal?)

Given the messages that I see in nextcloud.log, I suspect the problem is coming from recognize.

I also see the error Cannot redeclare function utf8_ord(). I’m typing this error message here for future reference, because I searched for it on Google, but did not get any relevant results.

Steps to replicate it (hint: details matter!):

  1. Update from 32.0.0 to 32.0.1

  2. Visit any page

Log entries

Nextcloud

Please provide the log entries from your Nextcloud log that are generated during the time of problem (via the Copy raw option from Administration settings->Logging screen or from your nextcloud.log located in your data directory). Feel free to use a pastebin/gist service if necessary.

PASTE HERE

Web Browser

If the problem is related to the Web interface, open your browser inspector Console and Network tabs while refreshing (reloading) and reproducing the problem. Provide any relevant output/errors here that appear.

{"reqId":"sP1zxMdgLgjOVcgtlkns","level":0,"time":"2025-10-30T16:17:19+00:00","remoteAddr":"94.226.251.213","user":"--","app":"serverDI","method":"GET","url":"/cloud/index.php/204","message":"The requested alias \"OCP\\IServerContainer\" is deprecated. Please request \"Psr\\Container\\ContainerInterface\" directly. This alias will be removed in a future Nextcloud version.","userAgent":"Mozilla/5.0 (Macintosh) mirall/4.0.1 (Nextcloud, macos-24.6.0 ClientArchitecture: arm64 OsArchitecture: arm64)","version":"32.0.0.13","clientReqId":"c1a07bfd-5b18-4ea2-8f1e-a8d0a5583546","data":{"app":"serverDI"}}

{"reqId":"sP1zxMdgLgjOVcgtlkns","level":3,"time":"2025-10-30T16:17:19+00:00","remoteAddr":"94.226.251.213","user":"--","app":"PHP","method":"GET","url":"/cloud/index.php/204","message":"Cannot redeclare utf8_ord() (previously declared in /home/tango/public_html/cloud/apps/recognize/vendor/scoper-autoload.php:55) at /home/tango/public_html/cloud/apps/suspicious_login/vendor/joomla/string/src/phputf8/ord.php#22","userAgent":"Mozilla/5.0 (Macintosh) mirall/4.0.1 (Nextcloud, macos-24.6.0 ClientArchitecture: arm64 OsArchitecture: arm64)","version":"32.0.0.13","clientReqId":"c1a07bfd-5b18-4ea2-8f1e-a8d0a5583546","data":{"app":"PHP"}}

Web server / Reverse Proxy

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

error_log is empty

Configuration

Nextcloud

The output of occ config:list system or similar is best, but, if not possible, the contents of your config.php file from /path/to/nextcloud is fine (make sure to remove any identifiable information!):

<?php
$CONFIG = array (
  'instanceid' => 'ocaeuadnc826',
  'passwordsalt' => '+',
  'secret' => '+p3pO',
  'trusted_domains' => 
  array (
    0 => 'tango.zone',
  ),
  'maintenance_window_start' => 1,
  'datadirectory' => '/home/yyy',
  'dbtype' => 'mysql',
  'version' => '32.0.0.13',
  'overwrite.cli.url' => 'https://yyy',
  'default_phone_region' => 'BE',
  'dbname' => 'yyy',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'yyy',
  'dbpassword' => 'yyy',
  'installed' => true,
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'ssl',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'tom',
  'mail_domain' => 'yyy',
  'mail_smtphost' => 'yyy',
  'mail_smtpport' => '465',
  'mail_smtpauth' => 1,
  'mail_smtpname' => 'yyy',
  'mail_smtppassword' => 'yyy',
  'maintenance' => false,
  'memories.db.triggers.fcu' => true,
  'memories.exiftool' => '/home/tango/public_html/cloud/apps/memories/bin-ext/exiftool-amd64-glibc',
  'memories.vod.path' => '/home/tango/public_html/cloud/apps/memories/bin-ext/go-vod-amd64',
  'memories.gis_type' => 1,
  'enabledPreviewProviders' => 
  array (
    0 => 'OC\\Preview\\Image',
    1 => 'OC\\Preview\\Movie',
  ),
  'theme' => '',
  'loglevel' => 0,
  'memories.vod.ffmpeg' => '/usr/bin/ffmpeg',
  'memories.vod.ffprobe' => '/usr/bin/ffprobe',
  'updater.secret' => 'yyy',
);

Apps

The output of occ app:list (if possible).

Tips for increasing the likelihood of a response

  • Use the preformatted text formatting option in the editor for all log entries and configuration output.
  • If screenshots are useful, feel free to include them.
    • If possible, also include key error output in text form so it can be searched for.
  • Try to edit log output only minimally (if at all) so that it can be ran through analyzers / formatters by those trying to help you.
2

Relevant bug reports:

1 Like
3

Will try right away what is suggested in those bug reports, many thanks!

4

Okay, as @mritzmann pointed out (many thanks again for that!), there are two relevant bug reports or this issue:

I tried renaming the recognize folder to recognize_, but since I still had to finish my update, that didn’t work, because the updater fails because of not finding the recognize directory. I renamed the directory back to its original name.

Another suggestion in these threads was to rename scoper-autoload.php to scoper-autoload.php.bak. From here, I could finish the update process. I took my instance out of maintenance mode with occ, all is functioning now (except recognize, I suppose).

As stated in these threads, the problem apparently lies not in recognize, but in suspicious login. To test this, I disabled suspicious login, renamed scoper-autoload.php.bak (a script from recognize) back to its original name scoper-autoload.php, and my instance is still fully functional.

1 Like