NC update from 31.0.7 to 31.0.9 get error

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):
    • 31.0.7
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubuntu 24.04
  • Web server and version (e.g, Apache 2.4.25):
    • nginx 1.24
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • traefik 3.4
  • PHP version (e.g, 8.3):
  • 8.3
  • Is this the first time you’ve seen this error? (Yes / No):
    • yes
  • When did this problem seem to first start?
    • when i update NC from 31.0.7 to 31.0.9
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • from command or ONline
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • no

Summary of the issue you are facing:

when i update NC from 31.0.7 to 31.0.9 ,it is over, but when i login ,web brower show:

Downgrading is not supported and is likely to cause unpredictable issues (from 31.0.9.1 to 31.0.7.1)

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

  1. sudo -u www-data php /var/www/nextcloud/updater/updater.phar

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.

PASTE

Web server / Reverse Proxy

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

PASTE HERE

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!):

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "192.168.10.78",
            "www.joesite.online",
            "nextcloud.joesite.online",
            "nextcloud.joesite.fun"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "overwriteprotocol": "https",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "31.0.7.1",
        "overwrite.cli.url": "http:\/\/192.168.10.78",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "allow_local_remote_servers": true,
        "onlyoffice": {
            "verify_peer_off": true,
            "jwt_secret": "***REMOVED SENSITIVE VALUE***",
            "jwt_header": "Authorization"
        },
        "maintenance": false,
        "theme": "",
        "loglevel": 0,
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379,
            "timeout": 0,
            "password": "***REMOVED SENSITIVE VALUE***"
        },
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "994",
        "mail_smtpsecure": "ssl",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "default_phone_region": "CN",
        "maintenance_window_start": 0,
        "app_install_overwrite": [
            "wopi"
        ]
    }
}

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.

Surprised there are no more reports of this issue (had it on 3 on my servers) nor any announcement of 31.0.9 being pulled back.

The “latest.zip” is still a 31.0.9 so perhaps it is OK for new installs, certainly does not work as an upgrade.

There is no trace of 31.0.9 even being released, according to Nextcloud server changelog .

For me, the upgrade went smoothly on multiple instances, so it’s definitely not a general issue. Although I upgraded from 31.0.8, so maybe there’s a bug that only causes issues when upgrading from 31.0.7 or older point releases..?

It was officially released last Thursday, but the changelogs on the website are often published a bit late. If I had to guess, it’s probably a manual process, and as we all know, those are the things that tend to be forgotten. :wink: You can find the changelogs on GitHub: Release v31.0.9 · nextcloud-releases/server · GitHub

Three instances, three times “Downgrading is not supported and is likely to cause unpredictable issues (from 31.0.9.1 to 31.0.8.1)” in my case. I upgrade one step only since NC18.

All my instances are textbook best practice configs.

Which version is installed according to config/config.php?

cat config/config.php | grep version

And which version is installed according to /status.php?

curl https://cloud.example.com/status.php

(or open /status.php in your browser)


@joe2014 I see that in your case, 31.0.7.1 is mentioned in config.php. Which makes sense. Does this also apply to /status.php?

OP wrote that they tried to upgrade from version 31.0.7 via CLI updater (updater.phar), which is supported, btw.

What does that even mean?

Please answer @mritzmann’s questions and consider posting your installation method and ‘textbook’ configurations here. It would also be helpful if you could describe in detail how you performed the upgrade, and any related log messages.

OK, I know the old method of tricking the NC instance to think it is of another version and forcing the upgrade, I thought you could elaborate on the failing upgrade process. For clarity, though:

'version' => '31.0.8.1',

"version":"31.0.8.1","versionstring":"31.0.8"

And this does not upgrade to 31.0.9 when using the procedure laid out in Upgrade manually — Nextcloud latest Administration Manual latest documentation - this part of the manual has always been broken BTW, but is still the closest to what a real-world terminal admin would do.
I am not using any other methods and I am not referring to or trying to enhance OPs post.

It does upgrade if using a method that is not recommended by the manual yet acceptable enough:
stop webserver, backup old NC folder → download and unpack latest.zip → copy files from latest.zip into existing NC folder → chown, chmod as in manual upgrade → start websersver and upgrade from command line → spend some time removing files that have not been replaced and are now redundant (the list of files to be removed will be provided by this very instance on the status screen).

@bb77, if you kindly didn’t rush me into answering other users’ questions? They asked the question literally minutes earlier, they do not need you to hurry me.
I would appreciate your comments on any issues in my config - this is from a backup of a test site that I was able to upgrade using the method laid out above. All others are configured the same way.

Click for config.php
<?php
$CONFIG = array (
  'instanceid' => 'instanceid',
  'passwordsalt' => 'passwordsalt',
  'secret' => 'secret +',
  'trusted_domains' =>
  array (
    0 => 'host.domain.local',
    1 => 'host.domain.tld',
  ),
  'trusted_proxies' =>
  array (
    0 => 'proxyip',
  ),
  'overwritehost' => 'host.domain.tld',
  'overwriteprotocol' => 'https',
  'overwrite.cli.url' => 'https://host.domain.tld/',
  'datadirectory' => '/mnt/nextcloud',
  'dbtype' => 'mysql',
  'version' => '31.0.8.1',
  'dbname' => 'nextcloud',
  'dbhost' => 'sql.domain.local:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'dbuser',
  'dbpassword' => 'dbpassword',
  'installed' => true,
  'skeletondirectory' => '',
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'filelocking.enabled' => 'true',
  'redis' =>
  array (
    'host' => '/run/redis/redis-server.sock',
    'port' => 0,
    'timeout' => 0.0,
  ),
  'log_type' => 'file',
  'logfile' => '/var/log/nextcloud.log',
  'loglevel' => 3,
  'logdateformat' => 'F d, Y H:i:s',
  'maintenance' => false,
  'maintenance_window_start' => 1,
  'default_phone_region' => 'uk',
  'mail_smtpmode' => 'smtp',
  'mail_smtphost' => 'mail.domain.tld',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'cloud',
  'mail_domain' => 'domain.tld',
  'mail_smtpport' => 'someport',
  'mail_smtpauth' => true,
  'mail_smtpname' => 'cloud@domain.tld',
  'mail_smtppassword' => 'mail_smtppassword',
  'app_install_overwrite' =>
  array (
  ),
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/var/www/nextcloud/apps',
      'url' => '/apps',
      'writable' => true,
    ),
  ),
  'forbidden_filename_basenames' =>
  array (
    0 => 'con',
    1 => 'prn',
    2 => 'aux',
    3 => 'nul',
    4 => 'com0',
    5 => 'com1',
    6 => 'com2',
    7 => 'com3',
    8 => 'com4',
    9 => 'com5',
    10 => 'com6',
    11 => 'com7',
    12 => 'com8',
    13 => 'com9',
    14 => 'comš',
    15 => 'com²',
    16 => 'comÂł',
    17 => 'lpt0',
    18 => 'lpt1',
    19 => 'lpt2',
    20 => 'lpt3',
    21 => 'lpt4',
    22 => 'lpt5',
    23 => 'lpt6',
    24 => 'lpt7',
    25 => 'lpt8',
    26 => 'lpt9',
    27 => 'lptš',
    28 => 'lpt²',
    29 => 'lptÂł',
  ),
  'forbidden_filename_characters' =>
  array (
    0 => '<',
    1 => '>',
    2 => ':',
    3 => '"',
    4 => '|',
    5 => '?',
    6 => '*',
    7 => '\\',
    8 => '/',
  ),
  'forbidden_filename_extensions' =>
  array (
    0 => ' ',
    1 => '.',
    2 => '.filepart',
    3 => '.part',
  ),
  'data-fingerprint' => 'custom_data_fingerprint',
);

Since I upgraded my test instance and one of the production instances this way and will not be upgrading the other production systems during daytime, I can only provide logs from the test instance. The symptoms of the failed update are visible in the logs:

Click for log excerpts
{"reqId":"LIH1F7swey37pFcLdUVM","level":0,"time":"September 14, 2025 17:31:54","remoteAddr":"","user":"--","app":"serverDI","method":"","url":"--","message":"The requested alias \"IntegrityCodeChecker\" is deprecated. Please request \"OC\\IntegrityCheck\\Checker\" directly. This alias will be removed in a future Nextcloud version.","userAgent":"--","version":"31.0.8.1","data":{"app":"serverDI"}}
(...)
{"reqId":"LIH1F7swey37pFcLdUVM","level":1,"time":"September 14, 2025 17:32:05","remoteAddr":"","user":"--","app":"updater","method":"","url":"--","message":"\\OC\\Updater::updateEnd: Update successful","userAgent":"--","version":"31.0.9.1","data":{"app":"updater"}}
{"reqId":"LIH1F7swey37pFcLdUVM","level":1,"time":"September 14, 2025 17:32:05","remoteAddr":"","user":"--","app":"updater","method":"","url":"--","message":"\\OC\\Updater::maintenanceDisabled: Turned off maintenance mode","userAgent":"--","version":"31.0.9.1","data":{"app":"updater"}}
{"reqId":"LIH1F7swey37pFcLdUVM","level":1,"time":"September 14, 2025 17:32:05","remoteAddr":"","user":"--","app":"updater","method":"","url":"--","message":"\\OC\\Updater::resetLogLevel: Reset log level to Error(3)","userAgent":"--","version":"31.0.9.1","data":{"app":"updater"}}
{"reqId":"Q0EyllRQKLMnyix8aIzj","level":3,"time":"September 14, 2025 17:33:57","remoteAddr":"redacted","user":"redacted","app":"core","method":"GET","url":"/index.php/apps/dashboard/","message":"Rendering themed error page failed. Falling back to un-themed error page.","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.6 Safari/605.1.15","version":"31.0.9.1","exception":{"Exception":"OCP\\HintException","Message":"Downgrading is not supported and is likely to cause unpredictable issues (from 31.0.9.1 to 31.0.8.1)","Code":0,"Trace":[{"file":"/var/www/nextcloud/lib/public/Util.php","line":534,"function":"needUpgrade","class":"OC_Util","type":"::"},{"file":"/var/www/nextcloud/lib/private/TemplateLayout.php","line":255,"function":"needUpgrade","class":"OCP\\Util","type":"::"},{"file":"/var/www/nextcloud/lib/private/legacy/OC_Template.php","line":120,"function":"__construct","class":"OC\\TemplateLayout","type":"->"},{"file":"/var/www/nextcloud/lib/public/AppFramework/Http/TemplateResponse.php","line":189,"function":"fetchPage","class":"OC_Template","type":"->"},{"file":"/var/www/nextcloud/lib/private/legacy/OC_Template.php","line":244,"function":"render","class":"OCP\\AppFramework\\Http\\TemplateResponse","type":"->"},{"file":"/var/www/nextcloud/index.php","line":35,"function":"printErrorPage","class":"OC_Template","type":"::"}],"File":"/var/www/nextcloud/lib/private/legacy/OC_Util.php","Line":990,"Hint":"Downgrading is not supported and is likely to cause unpredictable issues (from 31.0.9.1 to 31.0.8.1)","message":"Rendering themed error page failed. Falling back to un-themed error page.","exception":{},"CustomMessage":"Rendering themed error page failed. Falling back to un-themed error page."}}

In a successful upgrade, the first line is slightly different and carries the right NC version number (31.0.9.1) instead of 31.0.8.1. Seems to me the 31.0.9. upgrade somehow checks file integrity using 31.0.8 checksums and fails, leaving the NC instance in an ambiguous state (31.0.9 files but 31.0.8 in config.php).

Some things to check:

  • did you by chance have any other files *.config.php in your config/ folder? A common culprit is creating a backup and not realizing that all files named anything.config.php are read and merged to create the runtime config. If one is backup of your main config.php it’ll have overlapping and conflicting version numbers. Put backups elsewhere (or name them something that doesn’t have *.config.php in the name
  • opcache revalidation time settings (if they aren’t PHP defaults)

No, I know how config works. No, I do not have any other file in the /config folder (apart from .htacccess and MIME mapping). No, I do not backup to the same folder. My opcache revalidation time setting is 0 on purpose. This setting checks the timestamp on every request. Should the timestamp be unchanged, the file is served from cache, however all new files from an upgrade package (including config.php) have timestamps different than the previous version of NC, so no cached old files can are served. BTW I follow the best practices and stop both the webserver process and the php8-fpm service before upgrading, so opcache is cleared and starts fresh anyway.

My opcache revalidation time setting is 0 on purpose. This setting checks the timestamp on every request.

No, that disables checks entirely.

EDIT: To clarify we may be talking about slightly different things. To be more specific, the combo of opcache validations options is what matters. I’m thinking of opcache.validate_timestamps. If that is 0 for example, then opcache.revalidate_freq is ignored.

Should the timestamp be unchanged, the file is served from cache, however all new files from an upgrade package (including config.php) have timestamps different than the previous version of NC, so no cached old files can are served.

Not when checks are disabled.

One cause of what you’re seeing would be that the old installation’s version.php is being picked up still.

BTW I follow the best practices and stop both the webserver process and the php8-fpm service before upgrading, so opcache is cleared and starts fresh anyway.

It doesn’t start fresh per se. As soon as you start them back up to run the Updater, the existing (old) code loads.

In any case, based on your described config, at a minimum you’d have to restart php-fpm manually after the upgrade.

From the very link you have provided (PHP: Runtime Configuration - Manual):

I would appreciate if you familiarized yourself with the matter before shooting in the dark and giving “advice” you are clearly not ready to give.

1 Like

As I stated in my follow-up:

To be more specific, the combo of opcache validations options is what matters. I’m thinking of opcache.validate_timestamps . If that is 0 for example, then opcache.revalidate_freq is ignored

@TheWojtek Many people are active in this forum voluntarily and try to help, but your communication style is very rude. That’s why I stopped responding in this thread.

You may not notice this yourself, maybe (but that doesn’t matter).

My recommendation:

  • Please open your own thread. This thread was opened by @joe2014.
  • Consider how you want to be seen by others and don’t be rude.

You can respond to my post with whatever you want, but I won’t respond to it. I’m out.

@joe2014 Hi :waving_hand:. Do you still need help? :slight_smile:

While it is the opcache.validate_timestamps that actually enables and disables opcode cache, it wasn’t even mentioned and you stated that it is a 0 in a different directive that does this, which was misleading. This value is set to ‘enabled’ by default, BTW.

So you might have guessed that if I say “deliberately 0 because checks on every request”, the cache is enabled. It would not make any sense if I set the revalidation time to 0 and disable the cache. We have never mentioned the other directive before.

Also, even if you set the revalidation time to any number but disabled the opcode cache altogether by setting opcache.validate_timestamps to 0, the revalidation time does not apply so there is no “specific combo” as you tried to backtrack from a missed shot. It’s a different directive altogether that turns cache on and off and opcache.revalidate_freq has nothing to do with it.

Yes, that’s why I posted a quick method of solving this issue here. I can’t help but notice that anyone else didn’t help the OP with bringing his instance back online.

My communication style is merely precise and follows basic logic. I am sorry you find it rude. I have no problem with highlighting logical inconsequences or plain incompetence, since both of them do not help people with the issues they face.

This topic was automatically closed after 90 days. New replies are no longer allowed.