You are not logged in.
/usr/bin/runuser -u root -- /usr/bin/php /usr/share/webapps/nextcloud/occ upgrade An unhandled exception has been thrown: ParseError: syntax error, unexpected token "=>" in /etc/webapps/nextcloud/config/config.php:27 Stack trace: #0 /usr/share/webapps/nextcloud/lib/private/Config.php(68): OC\Config->readData() #1 /usr/share/webapps/nextcloud/lib/base.php(149): OC\Config->__construct('/usr/share/weba...') #2 /usr/share/webapps/nextcloud/lib/base.php(569): OC::initPaths() #3 /usr/share/webapps/nextcloud/lib/base.php(1076): OC::init() #4 /usr/share/webapps/nextcloud/console.php(49): require_once('/usr/share/weba...') #5 /usr/share/webapps/nextcloud/occ(11): require_once('/usr/share/weba...') #6 {main}
'apps_paths' => ( ( 'path'=> '/usr/share/webapps/nextcloud/apps', 'url' => '/apps', 'writable' => false, ), ( 'path'=> '/var/lib/nextcloud/apps', 'url' => '/wapps', 'writable' => true, ), ),
Looking through how to migrate to a Docker image I found that the syntax is wrong, it misses the arrays:
'apps_paths' => array (
0 => array (
'path' => '/usr/share/webapps/nextcloud/apps',
'url' => '/apps',
'writable' => false,
),
1 => array (
'path' => '/var/lib/nextcloud/apps',
'url' => '/wapps',
'writable' => true,
),
),
Someone should update the wiki? Sorry, it actually is correct. The mistake was on my side when replacing the square brackets with parenthesis. The wiki uses php's short array syntax.
The error messages are gone but it still cannot open the file /usr/share/webapps/nextcloud/occ when executing as nextcloud user
[root@server bin]# /usr/bin/runuser -u nextcloud -- /usr/bin/php /usr/share/webapps/nextcloud/occ upgrade
Could not open input file: /usr/share/webapps/nextcloud/occ
Edit: correct a wrong statement about the php syntax
Last edited by Wandinstallation (2021-02-23 12:39:41)
Offline
Are all permissions correct so that the nextcloud user can get access?
namei -l /usr/share/webapps/nextcloud/occ
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Online
The nextcloud package now depends on php version 8, but also optionally recommends uwsgi-plugin-php which uses php7. I continued running it with uwsgi, but the php 8 package is needlessly installed now.
Also the included /var/lib/nextcloud in the package conflicts (actually overrides) my service unit with `DynamicUser=true` and `StateDirectory=nextcloud` which creates a symlink /var/lib/nextcloud -> private/nextcloud
Offline
Are all permissions correct so that the nextcloud user can get access?
namei -l /usr/share/webapps/nextcloud/occ
[root@server nextcloud]# namei -l /usr/share/webapps/nextcloud/occ
f: /usr/share/webapps/nextcloud/occ
drwxr-xr-x root root /
drwxr-xr-x root root usr
drwxr-xr-x root root share
drwxr-xr-x root root webapps
drwxr-x--- root root nextcloud
-rwxr-xr-x root root occ
as it is supposed to be when following the new installation scheme? Hmm...
Looking at it it matches the warning I always get when the package is updated by pacman:
warning: directory permissions differ on /usr/share/webapps/nextcloud/ocs/
filesystem: 750 package: 755
and many more.
Changing the nextcloud folder to 755 gives me another error php messages. Executing
find . -type d -print0 | xargs -0 chmod 0755
from within the /usr/share/webapps/nextcloud folder fixes the wrong permissions and I was able to start the upgrade process!
It is definitely a permission problem that originates from the oc-perms script that I was executing after each update to "fix" the permissions.
Thanks for the hint!!
Offline
I cannot for the life of me get the new version to work. I've upgraded to php8 (all other php8 apps are working). Following each step in the wiki I am met with 500 errors complaining about permissions. The config files under /etc/webapps/nextcloud are owned by the nextcloud user. The files under /usr/share/webapps/nextcloud owned by root. Data and app directories owned by nextcloud.
From what I can tell in the wiki, php-fpm is the software that will allow the application to run with the nextcloud user account. I've added /etc/php/php-fpm.d/nextcloud.conf, added the service overrides and started php-fpm. It is running and has a nextcloud pool. On a whim I temporarily changed all nextcloud file ownership to http (like the old version). All of the file permission errors were gone and I was greeted with the normal upgrade page. This means that php-fpm isn't working. I think there might be a missing step to get apache to use it? Any ideas?
I've even tried uninstalling nextcloud and starting from scratch. Still cannot get past these permission errors.
Offline
It is definitely a permission problem that originates from the oc-perms script that I was executing after each update to "fix" the permissions.
If you remove read permissions for all users, then you'd have to recursively chown the nextcloud directory to the nextcloud user/group instead of root. All files that nextcloud does not read through php and are served by the webserver should be chowned to the webserver user.
If both need access to a directory you'll have to set up a shared group, allow anyone read access, use posix acl (setfacl), or run a webserver as the nextcloud user.
This means that php-fpm isn't working. I think there might be a missing step to get apache to use it? Any ideas?
You have to change the php handler for apache: https://wiki.archlinux.org/index.php/Ap … proxy_fcgi
Last edited by progandy (2021-02-22 21:34:59)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Online
Thanks progandy. I've now confirmed that php-fpm it self is working (thanks to php phpinfo()). Still getting the exact same errors with Nextcloud though. All the files it complains about are owned by root, which is what the wiki says it should be. Still getting permission errors when nextcloud tries to access the config at /etc/webapps/nextcloud. If I change the ownership to http those errors go away again. So there is something wrong with my fpm set up. Other than creating
/etc/php/php-fpm.d/nextcloud.conf
/etc/httpd/conf/extra/php-fpm.conf (and including it in the main http.conf)
and creating the override with systemctl edit php-fpm.service
what else needs to be done?
Last edited by piratebill (2021-02-22 22:39:59)
Offline
Trying to get nextcloud working but php8, but it just gives me the following error when attempting the upgrade command (either sudo -u http php occ upgrade or from the web upgrader):
Setting log level to debug
OC\DB\Exceptions\DbalException: Unknown database type bit requested, Doctrine\DBAL\Platforms\MariaDb1027Platform may not support it.
Update failed
Maintenance mode is kept active
Resetting log level
Offline
I cannot for the life of me get the new version to work. I've upgraded to php8 (all other php8 apps are working). Following each step in the wiki I am met with 500 errors complaining about permissions. The config files under /etc/webapps/nextcloud are owned by the nextcloud user. The files under /usr/share/webapps/nextcloud owned by root. Data and app directories owned by nextcloud.
From what I can tell in the wiki, php-fpm is the software that will allow the application to run with the nextcloud user account. I've added /etc/php/php-fpm.d/nextcloud.conf, added the service overrides and started php-fpm. It is running and has a nextcloud pool. On a whim I temporarily changed all nextcloud file ownership to http (like the old version). All of the file permission errors were gone and I was greeted with the normal upgrade page. This means that php-fpm isn't working. I think there might be a missing step to get apache to use it? Any ideas?
I've even tried uninstalling nextcloud and starting from scratch. Still cannot get past these permission errors.
Sorry, only a MeToo, also dozens of errors complaining about /usr/share/webapps/nextcloud/lib/private which has root:http-rights. Is there anyone, who get it to work with apache?
And I did so much changes in the past in so many config-files, because NC Security Warnings told me to do so.
It seems, now I have to understand them all.
I'm back to PHP7 and NC 20.0.7; tt-rss and wbce also don't "like" PHP8
Offline
Eventually, I got around all the problems and everything is sort of back to normal, except the apps that need to catch-up with NC21.
Now I got this permanent warning in the "Overview". Any ideas how to deal with it? It's here 3 days in a row since I upgraded:
"A background job is pending that checks for user imported SSL certificates. Please check back later"
The source code is pretty confusing, to be honest:
https://github.com/nextcloud/server/blo … icates.php
Personal spot :: https://www.smirky.net/ :: Try not to get lost!
Offline
Created a bug to add some sample config files for php-fpm and nginx to the package, please vote if you're interested https://bugs.archlinux.org/task/69752
Offline
Nextcloud 21 on Apache
So, I get it to work on a new fresh installed virtual machine and get rid of these
""Exception":"Error","Message":"touch(): Utime failed: Read-only file system at /usr/share/webapps/nextcloud/lib/private/Config.php#247" errors
https://wiki.archlinux.org/index.php/Ap … ing_libphp
did NOT work. So if you use(d) libphp, I think you have to undo all the changes in your /etc/httpd/conf/httpd.conf mentioned there
https://wiki.archlinux.org/index.php/Ap … proxy_fcgi with
https://wiki.archlinux.org/index.php/Nextcloud#php-fpm
works, but I had to put :
[Service]
ReadWritePaths=/var/lib/nextcloud/data
ReadWritePaths=/usr/share/webapps/nextcloud/apps
# Optional, if you've set 'config_is_read_only' => true in your config.php
ReadWritePaths=/usr/share/webapps/nextcloud/config
ReadWritePaths=/etc/webapps/nextcloud/config
in /etc/systemd/system/php-fpm.service.d/override.conf
although there is no "config_is_read_only" in my /etc/webapps/nextcloud/config/config.php, which I didn't touch
I'm using nextcloud in a subdirectroy, so my /etc/httpd/conf/extra/php-fpm.conf looks like that:
DirectoryIndex index.php index.html
<FilesMatch "\.php$">
SetHandler "proxy:unix:/run/php-fpm/php-fpm.sock|fcgi://localhost/"
SetHandler "proxy:unix:/run/nextcloud/nextcloud.sock|fcgi://localhost/"
</FilesMatch>
I've no idea if this is a correct syntax, but now both https://testserver/test.php and https://testserver/nextcloud works
As far as I remember I didn't do a chown or chmod anywhere
Offline
Anyone having a link to a "step by step tutorial" howto install Nextcloud 21 ? , I have Nextcloud 20 running on a vm where trying to upgrade fails miserably , tried a new installation of Nextcloud 21 that also failed.
Offline
nextcloud has become a nightmare. when i first installed it, the wiki was very specific and i just followed that. now its different. i just wasted an hour getting 21 to work, which was mostly just chown 'ing' the etc/config/nextcloud/config dir.
Offline
anyone have any idea how to fix this problem:
got nc running on php8. in settings/overview it is telling me to fix the database with occ db:add-missing-indices and occ db:add-missing-primary-keys. when i run them i get mermory error. i moved memory limit to 8GB in php ini. no matter what i set it to i get allocation error.
this is output:
"sudo -u http ./occ db:add-missing-primary-keys
PHP Warning: Version warning: Imagick was compiled against ImageMagick version 1802 but version 1803 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0
PHP Fatal error: Allowed memory size of 8589934592 bytes exhausted (tried to allocate 1052672 bytes) in /usr/share/webapps/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php on line 133"
i have done those fixes before and never had errors... any suggestions appreciated
Offline
nevermind, solved it, it was apc.enable_cli=1 needed in my apcu.ini file. disregard above, maybe this helps someone else using apcu memcache
Offline
Using nginx and uWSGI, I don't understand how the socket created by uWSGI – owned by the nextcloud user – is meant to be accessed by nginx.
Using the configuration from the package (without umask) or the configuration from the wiki (with umask = 027) doesn't work (nginx says it cannot access to the socket).
I could get it working by making the socket world-readable, with umask = 000, but that doesn't seem right.
/etc/uwsgi/nextcloud.ini
[uwsgi]
procname-master = %n
plugins = php
master = true
socket = /run/uwsgi/%n.sock
stats = /run/uwsgi/%n-stats.sock
uid = nextcloud
gid = nextcloud
umask = 000
...
$ namei -l /run/uwsgi/nextcloud.sock
f: /run/uwsgi/nextcloud.sock
drwxr-xr-x root root /
drwxr-xr-x root root run
drwxrwxr-x root nextcloud uwsgi
srwxrwxrwx nextcloud nextcloud nextcloud.sock
Another small point is the open_basedir, the one in the configuration from the package seems incomplete, I had to add:
`/var/log/nextcloud`, but I don't remember where I saw a warning or error
`/var/lib/nextcloud`, otherwise Nextcloud fails checking the setup in 'Administration > Overview' and logs an error: "File(/var/lib/nextcloud/apps/..) is not within the allowed path(s)" (note the '/..' at the end of the path)
Last edited by bonob (2021-02-25 17:50:28)
Offline
I don't know if it can be useful to anyone, but here is my experience. Was upgrading from Nextcloud 20 & php 7.4 to Nextcloud 21 & php 8. Apache, MySQL, w/o php-fpm. My Nextcloud data dir is /home/nextcloud, Apache is running by http:http user:group.
pacman's "-S nextcloud" stuck at
PHP Warning: Version warning: Imagick was compiled against ImageMagick version 1802 but version 1803 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0
and
Cannot write into "config" directory!
This can usually be fixed by giving the webserver write access to the config directory
Or, if you prefer to keep config.php file read only, set the option "config_is_read_only" to true in it.
I made sure that
# chown -R http:http /usr/share/webapps/nextcloud/ /var/lib/nextcloud/
Strings I added to /etc/webapps/nextcloud/config/config.php:
'logfile' => '/var/log/nextcloud/nextcloud.log',
'apps_paths' => [
[
'path'=> '/usr/share/webapps/nextcloud/apps',
'url' => '/apps',
'writable' => false,
],
[
'path'=> '/var/lib/nextcloud/apps',
'url' => '/wapps',
'writable' => true,
],
],
Changes I made to php.ini:
imagick.skip_version_check=1
open_basedir=/srv/http/:/tmp/:/usr/share/pear/:/usr/share/webapps/nextcloud/:/home/nextcloud/:/etc/webapps/nextcloud/config/:/var/lib/nextcloud/apps/:/dev/urandom/:/var/log/nextcloud/
Then
# systemctl restart httpd
# sudo -u http php /usr/share/webapps/nextcloud/occ upgrade
And it finally works.
Asus N61J/ATi Radeon HD5730
Toshiba A200/ATi Radeon HD2600
Offline
Ok, I give up this upgrade for now, it´s very annoying that an upgrade fails and a new install fails too, I tried to install Nextcloud 21 on a fresh install of Debian sid and that works as expected, waiting for arch wiki or someone else to make a step by step upgrade/install instruction, otherwise I move my data to a Debian/Nextcloud 21 vm.
Offline
Does anyone know why /var/lib/nextcloud/{data,apps} keep getting set to different ownership and permissions?
Personal spot :: https://www.smirky.net/ :: Try not to get lost!
Offline
> Using nginx and uWSGI, I don't understand how the socket created by uWSGI – owned by the nextcloud user – is meant to be accessed by nginx.
which is why I prefer to use systemd socket activation (which uwsgi supports). That way I can run the service as a DynamicUser= with very constrained privileges, while systemd can create the socket anywhere and with any permissions, and just pass it to uwsgi as a file descriptor.
Offline
I have the same issue here. Did you get any further? There is also an issue on github: https://github.com/nextcloud/server/issues/25746
miro279 wrote:I could start the update process, but it fails with an unhandled exception:
Starting code integrity check... An unhandled exception has been thrown: TypeError: decbin(): Argument #1 ($num) must be of type int, float given in /usr/share/webapps/nextcloud/3rdparty/phpseclib/phpseclib/phpseclib/Math/BigInteger.php:662 Stack trace: #0 /usr/share/webapps/nextcloud/3rdparty/phpseclib/phpseclib/phpseclib/Math/BigInteger.php(662): decbin() #1 /usr/share/webapps/nextcloud/3rdparty/phpseclib/phpseclib/phpseclib/Crypt/RSA.php(2848): phpseclib\Math\BigInteger->toBits() #2 /usr/share/webapps/nextcloud/3rdparty/phpseclib/phpseclib/phpseclib/Crypt/RSA.php(3177): phpseclib\Crypt\RSA->_rsassa_pss_verify() #3 /usr/share/webapps/nextcloud/lib/private/IntegrityCheck/Checker.php(371): phpseclib\Crypt\RSA->verify() #4 /usr/share/webapps/nextcloud/lib/private/IntegrityCheck/Checker.php(571): OC\IntegrityCheck\Checker->verify() #5 /usr/share/webapps/nextcloud/lib/private/IntegrityCheck/Checker.php(592): OC\IntegrityCheck\Checker->verifyCoreSignature() #6 /usr/share/webapps/nextcloud/lib/private/Updater.php(288): OC\IntegrityCheck\Checker->runInstanceVerification() #7 /usr/share/webapps/nextcloud/lib/private/Updater.php(132): OC\Updater->doUpgrade() #8 /usr/share/webapps/nextcloud/core/Command/Upgrade.php(255): OC\Updater->upgrade() #9 /usr/share/webapps/nextcloud/3rdparty/symfony/console/Command/Command.php(255): OC\Core\Command\Upgrade->execute() #10 /usr/share/webapps/nextcloud/3rdparty/symfony/console/Application.php(1009): Symfony\Component\Console\Command\Command->run() #11 /usr/share/webapps/nextcloud/3rdparty/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand() #12 /usr/share/webapps/nextcloud/3rdparty/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun() #13 /usr/share/webapps/nextcloud/lib/private/Console/Application.php(215): Symfony\Component\Console\Application->run() #14 /usr/share/webapps/nextcloud/console.php(100): OC\Console\Application->run() #15 /usr/share/webapps/nextcloud/occ(11): require_once('...') #16 {main}
I also had this problem, It seems it is a PHP8 bug for 32-bit systems. The workaround is changing `3rdparty/phpseclib/phpseclib/phpseclib/Math/BigInteger.php` line 662 from:
$bits = str_pad(decbin(hexdec(substr($hex, $i, 8))), 32, '0', STR_PAD_LEFT) . $bits;
to:
$bits = str_pad(decbin(intval(hexdec(substr($hex, $i, 8)))), 32, '0', STR_PAD_LEFT) . $bits;
Offline
Let me join the club of people not being able to get this to work. I have been using Nextcloud on Arch for lots of years (I think since owncloud 5) and this is the first time that after some hours of tinkering I cannot get the damn thing to work.
I am upgrading from Apache + PHP7 + Nextcloud 20 to PHP8 + Nextcloud 21. I have followed the instructions in the wiki and some more found here in the forum without success. I am trying to setup the server using the recommended php-fpm and nextcloud:nextcloud user, but without uWSGI.
I was getting error 500 and no error message at all on logs. Then I followed the wiki advice of installing and configuring mpm_itk. I do not know if I have fixed a problem or introduced a new one, now I get error 503. But at least now I have an error message in the logs. The problem is that Apache fails to open the php-fpm socket:
[Fri Feb 26 22:51:10.173556 2021] [proxy:error] [pid 15683] (13)Permission denied: AH02454: FCGI: attempt to connect to Unix domain socket /run/nextcloud/nextcloud.sock (*) failed
[Fri Feb 26 22:51:10.173676 2021] [proxy_fcgi:error] [pid 15683] [client 192.168.229.22:36624] AH01079: failed to make connection to backend: httpd-UDS, referer: https://redacted.com/owncloud/
Why it cannot connect? I do not know, socket is there and has http:http user:group:
srw-rw---- 1 http http 0 Feb 26 22:50 /run/nextcloud/nextcloud.sock
Maybe I have to give permission somewhere in the Apache configuration to the socket path?
Last edited by doragasu (2021-02-26 22:10:54)
Offline
Well, after giving up last week, I finally managed to get it working again.
Forget php8.
Like, seriously, don't even think of having it work with nextcloud 21. Install all php7-related packages, make sure you use php-fpm with the configs recommended in this thread (thank you very much again, guys!), chown the directories properly and you'll be alright.
There has been a SERIOUS lack of testing on this package and I don't have a clue how it ended up in community. It's the first breaking change that I encountered in ArchLinux in at least two years.
Offline
After hours of heavily scratching my head trying to upgrade my previous Apache and PHP install, I started configuring them from scratch, and finally got it to work (with PHP8 and the recommended php-fpm). I suspect my problem was related with my previous Apache configuration for nexctloud in nextcloud.conf, that had some options that might interfere with PHP8 and/or the php-fpm module.
These are the steps I followed:
1. Install nextcloud and PHP8 with required modules.
2. If you are on a 32-bit machine (I'm installing on a RaspberryPi 4 with 32-bit Archlinux Arm), patch BigInteger.php as I wrote in the post above. Otherwise code integrity checks will fail.
3. chown -R nextcloud:nextcloud to the nextcloud related paths as stated in the wiki and this forum.
4. Remove (backup first!) any files you had in your previous writable apps directory.
5. Review your config.php and make sure paths are OK. Remove any app_install_overwrite entry you might have there.
6. Remove (backup first!) any previously existing /etc/httpd/conf/httpd.conf, /etc/httpd/conf/extra/nextcloud.conf and /etc/php/php.ini
7. Follow the Apache setup in the Archwiki. When configuring apache PHP extensions, do **not** use libphp, go for php-fpm and mod_proxy_fcgi option.
8. Follow the Nextcloud setup in the Archwiki. Do not setup uWSGI.
That is what worked for me. The trick was reconfiguring Apache and PHP from scratch.
Nextcloud and PHP cause some headaches from time to time, but this has been too much, lucky me that I had several hours to spare this time.
Offline