Nextcloud breaks after upgrading to redis 7.2

Nextcloud version (eg, 20.0.5): 27.0.4 and 26.0.3
Operating system and version (eg, Ubuntu 20.04): debian 11
Apache or nginx version (eg, Apache 2.4.25): 2.4.56
PHP version (eg, 7.4): 8.2.8

The issue you are facing:

I did (a little bit too fast) a server update, there was a bunch of PHP updates (for 7.4, 8.1 and 8.2) and at the end, an update for Redis. After that suddenly 2 Nextcloud instances on that server stopped to work with a NC error (I have the Nextcloud background with a central box stating my IP and an error ID that changes each time I reload the page, it’s not a server error white on black).

After looking at error logs, trying to research the problem I finally did remember about that redis update, I removed my redis config from config.php and it started to work right away …

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

Yes, server has been running with redis for the last year at lesat !

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

'memcache.locking' => '\\OC\\Memcache\\Redis',
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => 'localhost',
    'port' => 6379,
    'timeout' => 1.5,
    'password' => 'xxxxxxxxxxxx',
    'dbindex' => 0,

I see the error on both a 27.0.4 and a 26.0.3 (PHP8.2 and PHP7.4) and it is definitely that redis upgrade that breaks. Redis was updated from 7.0.12.
I also tried migrating to a sock setup, same problem.
I ran through the changes that could affect my redis config and couldn’t find any, needless to say my Redis/NC config is pretty simple and has been working for a year …
Did anybody ran into the same problem ? Redis site says that 7.2 is like one day old, I’m surprised it went into the Debian repo so fast …


Are you, by chance, including experimental packages? Because Debian 11 definitely doesn’t support Redis 7.2:

I’d downgrade back to 7.0.x for the time being.

What was the error message (stack trace ideally) in the Nextcloud logs out of curiosity?


Thank you for your answer, I didn’t one second think about this type of incompatibility, the upgrade being proposed by apt I just did it without a second thought, I just checked my /etc/apt/sources.list :

deb bullseye main
deb-src bullseye main
deb bullseye-updates main
deb-src bullseye-updates main
deb bullseye-security main
deb-src bullseye-security main

and /etc/apt/sources.list.d :

redis.list  sury-debian-php-bullseye.list  virtualmin.list

I don’t see an “experimental” … maybe it’s coming from redis.list … ? I guess I won’t be the only one to get caught by this. I will have a look in the community forum of Virtualmin which I am using to manage that server.
I will try anyway to post here the error message, I will have to do it later that server being used right now !
Thanks !

1 Like

Yeah what’s the content of redist.list? That’s not standard on Debian.

Maybe check the timestamp on the file to see if that gives another clue where that config came from?

As for the error message, this is just the beginning, it’s very long, I’m not sure I can paste such a long text in here

{"reqId":"OO1l1fNMx7eOwm0Oz7Ug","level":3,"time":"2023-08-16T19:42:11+00:00","remoteAddr":"","user":"--","app":"index","method":"GET","url":"/index.php/apps/files/","message":"ERR AUTH <password> called without any password configured for the default user. Are you sure your configuration is correct?","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/116.0","version":"","exception":{"Exception":"RedisException","Message":"ERR AUTH <password> called without any password configured for the default user. Are you sure your configuration is correct?","Code":0,"Trace":[{"file":"/home/yyyyyyy/public_html/lib/private/RedisFactory.php","line":143,"function":"auth","class":"Redis","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/home/yyyyyyy/public_html/lib/private/RedisFactory.php","line":178,"function":"create","class":"OC\\RedisFactory","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/home/yyyyyyy/public_html/lib/private/Memcache/Redis.php","line":66,"function":"getInstance","class":"OC\\RedisFactory","type":"->"},{"file":"/home/yyyyyyy/public_html/lib/private/Memcache/Redis.php","line":72,"function":"getCache","class":"OC\\Memcache\\Redis","type":"->"},{"file":"/home/yyyyyyy/public_html/lib/private/App/InfoParser.php","line":58,"function":"get","class":"OC\\Memcache\\Redis","type":"->"},{"file":"/home/yyyyyyy/public_html/lib/private/App/AppManager.php","line":732,"function":"parse","class":"OC\\App\\InfoParser","type":"->"},{"file":"/home/yyyyyyy/public_html/lib/private/legacy/OC_App.php","line":434,"function":"getAppInfo","class":"OC\\App\\AppManager","type":"->"},{"file":"/home/yyyyyyy/public_html/lib/private/AppFramework/App.php","line":71,"function":"getAppInfo","class":"OC_App","type":"::"},{"file":"/home/yyyyyyy/public_html/lib/private/legacy/OC_App.php","line":155,"function":"buildAppNamespace","class":"OC\\AppFramework\\App","type":"::"},{"file":"/home/yyyyyyy/public_html/lib/private/AppFramework/Bootstrap/Coordinator.php","line":119,"function":"registerAutoloading","class":"OC_App","type":"::"},{"file":"/home/yyyyyyy/public_html/lib/private/AppFramework/Bootstrap/Coordinator.php","line":90,"function":"registerApps","class":"OC\\AppFramework\\Bootstrap\\Coordinator","type":"->"},{"file":"/home/yyyyyyy/public_html/lib/base.php","line":703,"function":"runInitialRegistration","class":"OC\\AppFramework\\Bootstrap\\Coordinator","type":"->"},{"file":"/home/yyyyyyy/public_html/lib/base.php","line":1180,"function":"init","class":"OC","type":"::"},{"file":"/home/yyyyyyy/public_html/index.php","line":34,"args":["/home/yyyyyyy/public_html/lib/base.php"],"function":"require_once"}],"File":"/home/yyyyyyy/public_html/lib/private/RedisFactory.php","Line":143,"CustomMessage":"--"}}


Ok I finally uninstalled all the redis packages and the redis.list repo, then started back using the regular debian repo which gave me a Redis v6 for Debian 11 Bullseye … this is the standard version for Bullseye. I could get v7.0.x using bullseye-backports but this could lead to other unwanted upgrades so for the time being I will stick with v6 !

Oh and the content of redis.list was:

deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] bullseye main

Which does mention “bullseye” as the debian version but still allows for an incompatible upgrade … weird !

Thank for for all your answers which did allow me to diagnose the problem, especially pointing the fact that Redis 7.2 is not Bullseye compatible !

1 Like

It’s an important principle in science and statistics, stating that the mere presence of a correlation between two variables doesn’t necessarily mean that one variable is the cause of the other:
“correlation does not imply causation.”

In other words: Don’t blame Bullseye, there is an open Issue about " Redis 7.2 compatibility" in the php-redis pecl module.

Sorry but I don’t quite understand your answer, well I understand what you say but not why you say it. I don’t think that I did blame Bullseye nor did I blame Nextcloud, I more or less did blame Redis (redis.list) for having a source file authorizing upgrade even though it’s not compatible (dependance not enforced …). I didn’t discuss at all the compatibility problem which I understand can (no, will) happen, I was wondering how I could get myself in a situation where my redis was updated even though it is not compatible.
But english not being my main language, I understand it is sometimes difficult to describe properly a problem.

1 Like

I have now been using redis 7.2.3 for a considerable time without having encountered any problems with php.
However, I did the installation directly from redis package archive, wich is working great for Debian/Ubuntu:

Much luck,

I have just completed a fresh install of next cloud on ubuntu22 with the nextcloud .sh installer. This installed php8.1 and redis 6.0.16.

I procced to manually upgrade php8.1 to php8.3 without issue. and then added the redis repo to ubuntu 22 and use apt upgraded redis to 7.2. After the ipgrade redis was no longer running and would not start at all. Logs where not very useful I kept seeing “User initiated shutdown”. I removed redis with apt and moved the /etc/redis/redis.conf to /etc/redis/redis.old. After a new install redis would start absoloutly fine but nextcloud app was no longer working it was giving an http1.1 500 error.

The new isntall of redis was now using a port and not unix socket for connectivity and nextcloud was not configured for port it was configured for socket. after some time reconfiguring redis.conf I found that the new version did not like “supervised no” and was causing the redis service to keep shuting down. I coppied the original /etc/redis/redis.conf from the script install of nextcloud and updated the line “supervised no” to “supervised auto” and everything worked fine.

I advise if using redis 7.2 and service will not stay running to check /etc/redis/redis.conf for a “supervised no” line and changed it to “supervised auto”