Same issue here.
Downgrading php (*, fpm, …( back to 7.3 is also not possible as nextcloud 18 seems to require php >= 7.4.
And downgrading nextcloud to 17 does also not work…
Please help us; it’s really bad to perform an update and then be unable to have a running instance!
I cannot confirm this assumption, because I’ve just upgrade a system with PHP 7.3 installed without any problem. The prerequisites of Nextcloud 18 are confirming that at least PHP 7.1 - 7.3 are working. Afaik support for PHP 7.4 has been added in the meantime too.
I found a solution here: https://bbs.archlinux.org/viewtopic.php?pid=1875352#p1875352
Set following settings in /etc/systemd/system/multi-user.target.wants/php-fpm.service and reload/restart the service.
ProtectHome=false
ProtectSystem=false
The better solution IMO is to move the actual config dir into the Nextcloud dir instead of having symlinks across the system directory structure. There is a good reason why many systemd units have those protection settings to deny access to /home /etc and other sensible directories. Keeping webserver + PHP access limited to the webroot only is safest and cleanest.
Not sure it’s a god idea to keep your home folder unprotected, unless you have nothing else than nextcloud data.
Something like this sould prevent others folders to be accessible from php-fpm.
ProtectHome=tmpfs
BindPaths=/home/your-nextcloud-folder
If you have more folders that need to be accessible, just add the others paths.
For the config file, you can add
ReadWritePaths = /etc/webapps/nextcloud/config/
so no others files will be accessible to php-fpm.
I had a look at my file system, and for me (ArchARM) the config was indeed symlinked.
$ ls -l /usr/share/webapps/nextcloud/config
lrwxrwxrwx 1 root http 29 Jan 24 16:44 /usr/share/webapps/nextcloud/config -> /etc/webapps/nextcloud/config
I tried removing the symlink and copying the folder, but this did not fix the error. However, as above, adding ProtectSystem=false to /usr/lib/systemd/system/php-fpm.service, then systemctl daemon-reload; systemctl restart php-fpm.service fixed it for me.
Is there a cleaner/safer way to fix this?
Brilliant. That works perfectly. Thank you!
Jep the ReadWritePath solution is definitely better than disabling the ProtectSystem security option completely. If this symlink is intended default, then /etc/webapps should be added as ReadWritePath to the php package be default? 