php, php8.1 etc are just meta packages which pull in any actual PHP implementation, like libapache2-mod-php8.1 (the default which I’d not recommend) , php8.1-fpm (which I’d recommend) or php8.1-cgi. Pick one of those, preferably PHP-FPM for any production system, instead of the meta package.
Just a bit of fun when upgrading Bullseye to Bookworm is for some reason if you use non-standard ports in Apache it will no longer work. I’ve spent hours troubleshooting and looking at configuration and log files trying to figure out why I couldn’t connect to port 444 which I use to access it internally. I use a reverse proxy to handle the external connections.
To see if the ports are being blocked I did broad port scans and noticed 444 never responded while port 443 did. Soon as I changed the port from 444 to 443 (standard https) in the apache ini file for nextcloud it worked. Oddly enough firewall is not enabled nor installed. Iptables shows nothing is being blocked so makes me wonder did something changed in Apache in terms of security?
Figured I throw this out there if you use non-standard ports.
Thank you for this tutorial! Have already racked my brain how I can solve this stupid situation. I wonder how many thousands of people are affected when they update from bullseye to bookworm! Hope the realize it before the update… 
2 Likes
How did you changed the ports, i.e. in which config file?
I just tested:
- Changed ports in
/etc/apache2/ports.conf - Adjusted default vhost accordingly in
/etc/apache2/sites-enabled/000-default.conf - Upgraded to Bookworm, including Apache2 to v2.4.57-2 and PHP to v8.2.7-1 (current latest von Debian Bookworm APT repo)
Nextcloud is reachable on changed port 81. Since I have no HTTPS enabled on this test instance, I did not test port 441. But the at least /etc/apache2/ports.conf remained unchanged.
This is such a wonderful resource. Thank you so much for posting this; you saved me from hours of frustration and unproductive effort! Thank you, thank you, thank you!
I had no problem with Nextcloud 25 to Nextcloud 26 and Debian Bullseye to Debian Bookworm see here.
1 Like
Theroetically this is not possible at all because NC26 does not support PHP7.4! That is why the upgrade to NC26 does not come with me at all.
At best you can raise debian to bookworm and then in the console NC25 to NC26. I will try this as soon as I have time.
But I can’t imagine that the upgrade from NC25 to NC26 worked. Probably you had already upgraded PHP to 8.X before.
The updater.phar is self-containing, has independent PHP requirements, is not invoking versioncheck.php and checks for available updates on its own. So indeed it should be possible to just run
sudo -u www-data php /path/to/nextcloud/updater/updater.phar
after upgrading Debian to Bookworm, and have all done in one step, without touching Nextcloud core files.
I am running currently another NC25 test instance on Debian Bullseye (PHP 7.4) for some hours, checking admin panel and running both, occ update:check and the updater.phar regularly, and I do not get the update offered. On my last test instance, after upgrading to Debian Bookworm, the update was offered immediately. I have not found it in the code, but while it contradicts devnull’s case, it all looks like there is some mechanism to not have it offered in the first place, if an incompatible PHP version does the check. And this applies for both, updater.phar, occ update:check and the admin panel (the latter two share the same code and cache anyway).
1 Like
I have 6x NC25 running with php 7.4 on debian 11. None of them shows the update to NC26. For me it’s clear why: PHP 7.4 is not supported with NC26 so the update is not possible.
But lets see if it works with the way you above (updating debian to bookworm and then run the updater in CLI).
Maybe channel “beta”?
I tried it with beta channel as well and it didn’t make a difference, also not after upgrading to the current NC25 RC. However, switching to beta channel is not applicable for production systems most of the time anyway: If an NC26 upgrade was offered, it would be a beta or RC version, if any available.
The motto of the day: No risk, no fun! 
I mounted my helmet and threw myself off the cliff…
First I upgraded Debian from 11 to 12.
After a reboot, NC25 stopped working as suspected. The reason is that PHP7.4 was uninstalled but PHP8.2 is missing.
Therefore I installed all PHP packages:
apt install php-apcu php-bcmath php-bz2 php-cgi php-cli php-curl php-fpm php-imagick php-intl php-json php-mbstring php-mysql php-opcache php-readline php-sqlite3 php-xml php-zip php-gd php8.2-gmp
Don’t forget to enable the cache in “/etc/php/8.2/cli/php.ini” “apc.enable_cli=1” and set memory from 128M to 512M in “/etc/php/8.2/fpm/php.ini”.
Then enable PHP:
a2enmod mpm_event
a2enconf php8.2-fpm
systemctl restart apache2
NC25 still does not work because now the message appears that it is not compatible with PHP8.2.
Now I have raised NC25 to NC26 with the above command “sudo -u www-data php /path/to/nextcloud/updater/updater.phar”.
Immediately the update to NC26.0.2 is offered and executed.
Now NC26 is running.
I think thanks to the helmet everything worked! 
3 Likes
Side note: With this you have both installed and enabled: PHP-FPM with its Apache handler, as well as the internal Apache PHP module. I am surprised that those do not conflict loudly, probably because FPM works only with event or worker MPM while the module works only with prefork MPM. You however should have seen related warnings when running a2enmod. Nowadays, PHP-FPM is recommend for most or all setups. So you should be able to disable and uninstall the PHP module:
a2dismod php8.2
a2dismod mpm_prefork
a2enmod mpm_event
a2enmod php8.2-fpm
systemctl restart apache2
# check whether everything is working
apt purge libapache2-mod-php
Reverting this in opposite order re-enables the PHP module. The module has the downside that every single client connection uses (in case spawns) an own Apache process (prefork MPM) with a whole new PHP instance. This slows down client connections and increases RAM usage significantly on concurrent access, and it breaks caching in PHP. The event MPM will spawn a number moreless static Apache processes with a fixed number of worker threads which can hence each handle a large number of requests. And PHP-FPM can maintain one OPcache and APCu instance for all Nextcloud visitors, being a performance benefit and uses less peak RAM, especially when multiple clients access concurrently.
1 Like
Thanks for the explanation. I tried it but get:
a2enmod php8.2-fpm
ERROR: Module php8.2-fpm does not exist!
No clue why. 
Edit: Strange, it has worked before i think.
Edit2: Side note, update to NC27 is now also possible on stable channel after update debian and PHP!
Ah sorry, it is a config, not a module:
a2enconf php8.2-fpm
1 Like
Ah perfect, now it has worked! 
I will edit my post.
Edit:
After the relatively soft landing before, I put my helmet on and jumped again… 
On the second server, php8.2 was already installed after the debian upgrade. So all i had to do is:
a2enmod mpm_event
a2enconf php8.2-fpm
systemctl restart apache2
And then start the NC update.
Works fine so far.
1 Like
I updated more instances and it worked fine. But now, with the most important one, I’m stuck. 
The update command has updated from 25.0.7 to 25.0.8. The problem now is that I can not update to 26.x.x because this is not available. It says 25.0.8 is the latest.
Any idea how to get him to continue to update to 26.x.x?
This is expected if there is a newer subversion available. Easiest is to apply the latest offered update before doing the Debian/PHP upgrade.
However, you can apply the NC 25.0.8 update now, re-apply the versioncheck.php patch for PHP 8.2 support and should then be offered NC26. It should be also possible to skip the patch and use the CLI updater instead:
sudo -u www-data php /var/www/nextcloud/updater/updater.phar
Thanks for the help. I have updated to 25.0.8 (with updater.phar) but now 26.0.x is not offered for update if i run updater.phar again. Is there a way to “force” update check again?
You are definitely on PHP 8.2 now? php -v
I am not sure how exactly it works, but saw a 30 minutes cache for update checks. So probably give it that time before trying other things. Also changing the channel to beta and back to stable might help.
I am not aware of a way to force an update if it was not offered, aside of applying it manually: Upgrade manually — Nextcloud latest Administration Manual latest documentation