Yes the directory has the proper permissions from what I can tell
[alarm@alarmpi webapps]$ pwd
[alarm@alarmpi webapps]$ ls -alh
drwxr-xr-x 3 root root 4.0K Oct 5 20:45 .
drwxr-xr-x 59 root root 4.0K Dec 2 21:39 ..
drwxr-xr-x 3 http http 4.0K Nov 11 16:21 nextcloud
When reinstall the php version
pacman -U /var/cache/pacman/pkg/php-7.3.11-1-armv7h.pkg.tar.xz
I get this message when go to the nextcloud page
Internal Server Error
The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.
I have exactly the same issue with php 7.4 and when I downgrade, I have the same message too !
Did you find a solution @mangoTango ?
Hey @Clement, this topic is has effected a couple of people. I found that someone used downgrade on arch to get it to work. For my part mine is still broken. That is quite bad.
Ok thanks, keep me informed if you find something…
make sure to manually downgrade all relevant php-modules, too - not just the “main” prog.
For my part, I did that yesterday, downgrade all php modules and in my php logs I have this :
[16-Dec-2019 21:57:33 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'apcu.so' (tried: /usr/lib/php/modules/apcu.so (/usr/lib/php/modules/apcu.so: undefined symbol: php_error_docref), /usr/lib/php/modules/apcu.so.so (/usr/lib/php/modules/apcu.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
[16-Dec-2019 21:57:33 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'apc.so' (tried: /usr/lib/php/modules/apc.so (/usr/lib/php/modules/apc.so: undefined symbol: apc_iterator_obj_init), /usr/lib/php/modules/apc.so.so (/usr/lib/php/modules/apc.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
[16-Dec-2019 21:57:33 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'igbinary.so' (tried: /usr/lib/php/modules/igbinary.so (/usr/lib/php/modules/igbinary.so: undefined symbol: zend_get_properties_for), /usr/lib/php/modules/igbinary.so.so (/usr/lib/php/modules/igbinary.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
[16-Dec-2019 21:57:33 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'imagick' (tried: /usr/lib/php/modules/imagick (/usr/lib/php/modules/imagick: cannot open shared object file: No such file or directory), /usr/lib/php/modules/imagick.so (/usr/lib/php/modules/imagick.so: undefined symbol: php_error_docref)) in Unknown on line 0
[16-Dec-2019 21:57:33 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'redis' (tried: /usr/lib/php/modules/redis (/usr/lib/php/modules/redis: cannot open shared object file: No such file or directory), /usr/lib/php/modules/redis.so (/usr/lib/php/modules/redis.so: undefined symbol: php_error_docref)) in Unknown on line 0
And they are in the folder /usr/lib/php/modules/ with the right 755 for the user root.
You have to make sure that the required library packages are installed on your server too, to get rid of the
cannot open shared object file messages.
Hey, So I found a temporary solution, I have downgraded and I remove all the php extensions, seems to work, but it’s really slow and i have some issue (nothing really bad)
Have you tried to edit php-pfm service as mentionned on archlinux bugtracker?
I had almost the same problem and explained hw to resolve it here: Problem to acces data folder after upgrade to 18.0.0 RC1
So yesterday was the 18 update. but now I get the permissions error even tough the permission should be right
I tried the suggestion of @quiwy but still no progress
drwxr-xr-x 13 http http 4096 Jan 19 10:10 .
drwxr-xr-x 3 root root 4096 Oct 5 20:45 ..
drwxr-xr-x 33 http http 4096 Jan 19 10:09 3rdparty
drwxr-x--- 51 http http 4096 Jan 19 10:10 apps
-rw-r--r-- 1 http http 15752 Jan 18 20:51 AUTHORS
lrwxrwxrwx 1 http http 29 Jan 18 20:51 config -> /etc/webapps/nextcloud/config
-rw-r--r-- 1 http http 3910 Jan 18 20:51 console.php
-rw-r--r-- 1 http http 34520 Jan 18 20:51 COPYING
drwxr-xr-x 23 http http 4096 Jan 19 10:10 core
-rw-r--r-- 1 http http 5048 Jan 18 20:51 cron.php
drwxr-xr-x 2 http http 4096 Oct 9 22:12 data
-rw-r--r-- 1 http http 2537 Jan 18 20:51 .htaccess
-rw-r--r-- 1 http http 156 Jan 18 20:51 index.html
-rw-r--r-- 1 http http 2976 Jan 18 20:51 index.php
drwxr-xr-x 6 http http 4096 Jan 19 10:10 lib
-rwxr-xr-x 1 http http 283 Jan 18 20:51 occ
drwxr-xr-x 2 http http 4096 Jan 19 10:10 ocm-provider
drwxr-xr-x 2 http http 4096 Jan 19 10:10 ocs
drwxr-xr-x 2 http http 4096 Jan 19 10:10 ocs-provider
-rw-r--r-- 1 http http 3056 Jan 18 20:51 public.php
-rw-r--r-- 1 http http 5235 Jan 18 20:51 remote.php
drwxr-xr-x 4 http http 4096 Jan 19 10:10 resources
-rw-r--r-- 1 http http 26 Jan 18 20:51 robots.txt
-rw-r--r-- 1 http http 2381 Jan 18 20:51 status.php
drwxr-xr-x 3 http http 4096 Jan 19 10:10 themes
drwxr-xr-x 2 http http 4096 Jan 19 10:10 updater
-rw-r--r-- 1 http http 101 Jan 18 20:51 .user.ini
-rw-r--r-- 1 http http 363 Jan 18 20:51 version.php
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.
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.
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
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?