Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#64689 - [nextcloud] PHP 7.4 upgrade breaks nextcloud

Attached to Project: Community Packages
Opened by Bjoern Franke (bjo) - Saturday, 30 November 2019, 01:15 GMT
Last edited by Sergej Pupykin (sergej) - Saturday, 18 January 2020, 22:45 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 45
Private No


Nextcloud throws an error message "This version is only compatible with PHP <= 7.3".

Additional info:
* php 7.4.0
* nextcloud 17.0.1-1

It seems the nextcloud devs were unable to test against 7.4 yet, see
This task depends upon

Closed by  Sergej Pupykin (sergej)
Saturday, 18 January 2020, 22:45 GMT
Reason for closing:  Fixed
Comment by loqs (loqs) - Saturday, 30 November 2019, 02:55 GMT
If you modifiy /usr/share/webapps/nextcloud/lib/versioncheck.php
if (version_compare(PHP_VERSION, '7.4.0') !== -1) {
if (version_compare(PHP_VERSION, '7.5.0') !== -1) {
can you progress any further?
Comment by wommel (wommel) - Saturday, 30 November 2019, 06:32 GMT
also needed to add an override for php-fpm containing:

ReadWritePaths = /usr/share/webapps/nextcloud/data
ReadWritePaths = /usr/share/webapps/nextcloud/apps
ReadWritePaths = /etc/webapps/nextcloud/config/

besides that just some deprecation warnings, nothing serious
Comment by Bjoern Franke (bjo) - Saturday, 30 November 2019, 11:20 GMT
@wommel So every path used by webapps has to be added into the php-fpm.service? That does not sound very practical.
Comment by Bjoern Franke (bjo) - Saturday, 30 November 2019, 11:50 GMT
Changing the version as suggested by @loqs and setting ReadWritePaths to /etc/webapps and /usr/share/webapps let NC work with PHP 7.4.
Comment by wommel (wommel) - Saturday, 30 November 2019, 15:34 GMT
no only the two paths in /usr and maybe /etc need write access.

having program data in /usr is somewhat wrong. the more standard conform way would be to have the two paths in /var/lib/nextcloud.
so only the data and apps dirs shoud be either allowed or moved (phpfpm has no special write restriction in /var besides the usual user/group based stuff).
allowing writes to /usr would allow an attacker who found a bug in any of your fpm served apps to modify the code it runs and not just the data.
write acces to /usr ist intentionaly and rightfully denied by fpm.
the webapp packages could either provide their necessary overrides as /usr/lib/systemd/system/php-fpm.service.d/$appname.conf or create /var/lib/webapps/$appname/ folders and use symlinks in /usr but that could be critical on updates.

a daemon having write access to its config file is in general debatable. thats why nextcloud offers the config option "config_is_read_only" so it stops complaining about missing write access. but you may have some problems on install & update if done via the webinterface (the fpm restrictions do obviously not apply to the cmd tool but careful about the user running it).
Comment by Branimir Amidzic (ambra) - Saturday, 30 November 2019, 20:26 GMT
I wouldn't recommend editing "/usr/share/webapps/nextcloud/lib/versioncheck.php" until Nextcloud is tested with PHP 7.4.
I think that the maintainer of the package should specify package requirements to PHP 7.2 and 7.3, so that PHP don't get updated if there's Nextcloud installed.

Comment by Olav Seyfarth (nursoda) - Saturday, 30 November 2019, 21:38 GMT
Adding the dependency seems the right way. Should be done.

However, I suspect that there are quite some installations downloaded from and installed manually out there. Adding a warning to PHP or PHP-FPM doesn't seem reasonable though since only a small fraction of PHP users will have nextloud installed (manually). Not sure what is the right way to handle this kind of "dependency".
Comment by Bjoern Franke (bjo) - Saturday, 30 November 2019, 21:48 GMT
@wommel In the actual situation, NC writes it's apps downloaded via webinteface also to /usr/share/webapps, maybe seperate app_path needs to be defined.
Comment by loqs (loqs) - Sunday, 01 December 2019, 15:14 GMT
If the data and apps dir was set in config.php to be under /var would that not reduce the number of ReadWritePaths needed?
Additionally if config_is_read_only is set to true then could nextcloud be used without a service override?
Although this would prevent some configuration via the web interface.
Comment by Bjoern Bidar (Thaodan) - Sunday, 01 December 2019, 20:22 GMT
There are patches to fix/add php 7.4 support that are comming in 18.x maybe adapt them:
Comment by Bjoern Bidar (Thaodan) - Sunday, 01 December 2019, 20:28 GMT
For a config to /var/lib/nextcloud see here:

Should work also when using php-fpm (I'm using uwsgi).

$CONFIG = array (
'datadirectory' => '/var/lib/nextcloud/data',
'cache_path' => '/var/lib/nextcloud/cache',

'log_type' => 'systemd',
'loglevel' => 2,


Setting the cache dir also keep user dirs from being crowded when using /home as data dir for user data. E.g. for example when users in nextcloud and in the system are the same because of ldap.
Comment by Olav Seyfarth (nursoda) - Monday, 02 December 2019, 07:25 GMT
In the Nextcloud PR (, Thaodan stated in respect to Arch not providing php-7.3 + php-7.4 in parallel: "distros should backport fixes if the software needs fixes". alerque argued: "7.3 → 7.4 is not a major version change that distros should be expected to check every webapp against. The latest 7.x should be workable and it is incumbent on projects like this one to support it. Distros shouldn't have to backport a bunch of patches to run on the latest interpreter, if anything only the opposite scenario should be necessary."

Alternatives for those that use Arch repo PHP and non-repo Nextcloud:

stick to PHP 7.3 (by pinning all packages in /etc/pacman.conf like this:
IgnorePkg = php php-apcu php-fpm php-gd php-igbinary php-imagick php-intl php-redis
Downside: Uncertain what to do IF security relevant patches for one of those packages emerge.

upgrade to PHP 7.4 as soon as NC 18 becomes available (NC 18 supports PHP 7.4)
NC 18 beta will be available mid December 2019 (~ 2 weeks)
NC 18 release is scheduled for mid January 2020 (~ 6 weeks)

immediately upgrade to PHP 7.4 but modify the "required" tests in NC 17 without NC 17 having been tested against PHP 7.4
Comment by loqs (loqs) - Monday, 02 December 2019, 16:53 GMT Comment by Pierre Schmitz (Pierre) - Monday, 02 December 2019, 18:01 GMT
PHP 7.3 to 7.4 was a minor update. It is not expected to break software. I wonder why NC has this runtime check at all.
Comment by Christoph Seitz (go2sh) - Tuesday, 03 December 2019, 20:22 GMT
PHP do break stuff though only changing the minor version number. They don't do strict semantic versioning. See
And I think PHP 7.4 is light on the changes. This is one of the reasons, why most distros supply seperate minor version packaging.
Comment by Daniel (SeeSpotRun) - Tuesday, 03 December 2019, 23:15 GMT
Quick rollback to 7.3.9 EDIT: to 7.3.12, thanks @nursoda:
$ for pkg in "" "-fpm" "-gd" "-intl"; do sudo pacman -U"$pkg"/php"$pkg"-7.3.12-1-x86_64.pkg.tar.xz; done
$ sudo pacman -U

Or if the packages are already cached:
for pkg in "" "-fpm" "-gd" "-intl"; do sudo pacman -U /var/cache/pacman/pkg/php"$pkg"-7.3.12-1-x86_64.pkg.tar.xz; done
sudo pacman -U /var/cache/pacman/pkg/php-apcu-5.1.18-1-x86_64.pkg.tar.xz

Comment by Olav Seyfarth (nursoda) - Wednesday, 04 December 2019, 22:16 GMT
7.3.12 was the latest PHP 7.3 version, so why 7.3.9?
I followed this:
I set back to this /etc/pacman.d/mirrorlist:
and rolled back system with pacman -Syyuu.
Then I pinned 7.3 packages with this line in /etc/pacman.conf:
IgnorePkg = php php-apcu php-fpm php-gd php-igbinary php-imagick php-intl php-redis
After that, I restored the original mirrorlist and continued to keep the rest of the system up-to-date with pacman -Syu
Comment by Willy J (xananax) - Thursday, 05 December 2019, 13:19 GMT
EDIT: Nope, it's all broken and I am unable to fix it.

previous message:
I have a custom install of nextcloud, but I think this is still relevant:

I've followed the suggestion by loqs.

I've applied the changes here:

For this one:

I've entered "3rdparty" and ran

sudo composer require "swiftmailer/swiftmailer:6.2.3"

Then I chowned the newly installed directories back to http:http:

sudo chown -R http:http 3rdparty/swiftmailer && sudo chown -R http:http 3rdparty/symfony

Then I edited `lib/versioncheck.php` and changed `7.4.0` with `7.5.0`

I then restarted php-fpm and nginx

sudo systemctl restart php-fpm
sudo systemctl restart nginx

Things seem to be working fine-ish.

The desktop file syncing app works correctly.
The Password app for example isn't syncing correctly with the Firefox password extension. Maybe I'll discover other problems as I go along.
But I figure I can hold on 2 weeks this way until the nextcloud update comes along
Comment by Dario Pellegrini (DarioP) - Friday, 06 December 2019, 13:51 GMT
When trying to temporary revert php back to 7.3 (see Daniel's comment) I encountered this other bug:
I had to wget the packages locally before installing them, clearing the cache might have worked too.
Comment by bobpaul (bobpaul) - Saturday, 07 December 2019, 02:59 GMT
This same thing happened during the php7.2 to php7.3 upgrade. (NC16 required <7.2, NC17 added 7.3). It probably going to happen next year, too. PHP minor versions introduce breaking changes and have long support cycles. As such I really don't think anyone's ever going to convince the Nextcloud devs to change their policy around testing/supporting PHP updates mid release.

Perhaps Nextcloud should be pushed back into to AUR where having multiple versions of a package is more palatable? Upgrading right away to NC18 might not always be desirably anyway as plugins tend to lag behind, so multiple versions of nextcloud and multiple versions of php in AUR would probably offer a better user experience.
Comment by Daniel (SeeSpotRun) - Saturday, 07 December 2019, 04:21 GMT
@nursoda, you're correct, my mistake. I was just looking at the directory listing in alphabetical order. Will edit my earlier post.
Comment by Olav Seyfarth (nursoda) - Monday, 09 December 2019, 00:52 GMT
NC 18 beta is available on beta channel through the admin interface now. However, this is the CURRENT list of apps. Surely, many apps will be updated during the next weeks, and they may work now, but some may not, and I expect that I takes rather long until all of them are fully PHP 7.4 compatible. Here's the list of my test instance, sorted for my personal app importance. Edit: Updated list Dec, 24:

===== WITH Update/Compatibility for NC 18 =====


Group folders
Collabora Online

Two-Factor Admin Support
Two-Factor Authentication via Nextcloud notification
Two-Factor TOTP Provider
Two-Factor U2F
Two-Factor Gateway

Suspicious Login

File access control
Files automated tagging
Preview Generator
Automated PDF conversion
Video converter
Custom CSS
Link editor

===== WITHOUT Update for NC 18 (may or may not be compatible) =====


Mind Map
Social sharing via email
Simple poll for Nextcloud Talk
Time Tracker
Two Factor e-mail provider
Ransomware protection
Terms of service
Data Request
Markdown Editor

Quota warning
Ransomware recovery
INotify file watcher
Files From Mail
Brute-force settings
Announcement center
Audio Player
Audio Player - ID3 Editor (add-on)
Camera RAW Previews
Flow Upload
External sites
Full text search - Files
Activities for shared file downloads, visible to all admins
Full text search
Phone Sync
Optical character recognition
Favorites Quickaccess Sorting
Quick notes
SMB connection test
Upload Details
External user authentication
User retention

Additional Note: After upgrading NC 17 to 18 beta on his Raspberry Pi running Arch with PHP 7.4 my son got segfaults. So I'll still wait a bit…
Comment by Caleb Maclennan (alerque) - Monday, 09 December 2019, 07:23 GMT
> PHP 7.3 to 7.4 was a minor update. It is not expected to break software. I wonder why NC has this runtime check at all.

In spite of being the one to argue this point on the NC issue (and I think it's true), I can understand where they are coming from. PHP has an absolutely terrible track record of breaking changes in minor releases. I remember this being a problem 15 years ago and it's still a problem in the last few cycles. Blocking future releases with this kind of check actually makes sense. Sadly. What doesn't make sense is their refusal to do anything about their own development timeline. In this case they have the patches, it would not be that hard to backport them to a point release. In my case everything works just dropping the runtime check. Obviously that doesn't work for all apps, but 7.4 doesn't have huge changes that they need to rework all their code for. They could have (and I think should have) backported 7.4 support as soon as (or even before) it was announced. The dev cycle on PHP is plenty long to see these things coming and put out minor updates to stay compatible before things break. The dogged expectation that distros should keep old releases around is what should change here.

Given that we've been round this merry go round a couple times and the NC folks aren't seeing the light, I would suggest from the Arch side that this package matches the internal check and explicitly requires the same version range as is being checked for at runtime. This would block system updates from breaking systems — not just now but in future cycles as well. Then when standoffs like this occur on a case by case basis we can look into what it takes to unblock the updates: whether that is patches or beta versions or whatever.
Comment by Sergio (arknix) - Wednesday, 11 December 2019, 07:22 GMT
After applying versioncheck.php hack you also need to disable PHP 7.4 new system protection:

sed 's/ProtectSystem=full/ProtectSystem=false/g' /usr/lib/systemd/system/php-fpm.service -i
systemctl daemon-reload
systemctl restart php-fpm.service
Comment by Musikolo (Musikolo) - Thursday, 19 December 2019, 04:03 GMT
I cannot agree more with @bobpaul. Every year or so the same story repeats over and over.

Why don't we have depends=('php<7.4' 'php-gd')?

When nextcloud 18 is released, we should have depends=('php<7.5' 'php-gd') instead.

This would ensure things like this never repeat again...
Comment by Kilian (9-R) - Friday, 20 December 2019, 16:36 GMT
I would suggest putting that change in an override file to the systemd unit like this:

mkdir /etc/systemd/system/php-fpm.service.d
echo "ProtectSystem=false" > /etc/systemd/system/php-fpm.service.d/overide.conf

It is bad practice to modify the systemd units in /usr/lib/systemd/system/ directly.

An even better solution would be to just exclude the folders that actually need write access from read-only-mode with

see documentation for details:
Comment by Bjoern Bidar (Thaodan) - Friday, 20 December 2019, 19:19 GMT
Or use systemctl edit <unit> and paste.
Comment by Natanji (Natanji) - Tuesday, 31 December 2019, 13:01 GMT
I agree with @bobpaul and @Musikolo. Why the hell do we have this every single year? The package maintainer should add the versioned dependency to this package that is clearly communicated by the Nextcloud developers. PHP minor updates always introduce some incompatibilities and those will naturally affect a complex software like Nextcloud.
Comment by Doron Behar (doronbehar) - Wednesday, 01 January 2020, 20:54 GMT
So today I noticed the nextcloud package was signed today - 1.1.2020 and the version is 17.0.2. Is it safe to upgrade now?
Comment by Sergej Pupykin (sergej) - Wednesday, 01 January 2020, 21:06 GMT
I think no, versioncheck.php still mentions 7.4.0.