Owncloud 10.0.3 (Centos VPS) issues after upgrade from 9.1.5

OK after upgrading Owncloud to 10.0.3, it complained that php was outdated (I had 5.4.16) so I managed to upgrade it to 7.1.9. Then all seemed fine until I went to use my cloud and noticed atrocious performance (I was away using the web at that moment so I blamed internet connection for slow performance). Today I am using it locally (on LAN), and I still see performance issues and other problems.

Issues:

  1. When I login I immediately see a yellow tool-tip at the top of the page saying "Problem loading page, reloading in 5 sec" then the contents appears.

  2. Today I had issue when logging in as admin, I was getting "CSRF Check failed -- Access Forbidden". After I rebooted the VPS this issues went away (for now...)

  3. Some files failed to download (Firefox was throwing failed status, or error messages such as "The file could not be saved, because the source file could not be read"


Steps to reproduce

  1. Upgrade to 10.0.3

Expected behaviour

The above problems should not occur

Actual behaviour

See above

Server configuration

Centos 7.4

Web server:
Server version: Apache/2.4.6 (CentOS)
Server built: Apr 12 2017 21:03:28

Database:
MariaDB (running on remote VPS)

PHP version:
PHP 7.1.9 (cli) (built: Sep 14 2017 19:40:34) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies

ownCloud version: (see ownCloud admin page)
10.0.3 Stable

Updated from an older ownCloud or fresh install:
Upgraded

Where did you install ownCloud from:
Centos repo

The content of config/config.php:

<?php
$CONFIG = array (
  'instanceid' => 'xxxxxxxxxxxxxxxxxx',
  'passwordsalt' => 'xxxxxxxxxxxxxxxxxx',
  'trusted_domains' =>
  array (
    0 => 'xxxxxxxxxxxxxxxxxx',
    1 => 'xxxxxxxxxxxxxxxxxx',
  ),
  'datadirectory' => '/mnt/data',
  'enable_previews' => 'false',
  'overwrite.cli.url' => 'https://localhost/',
  'dbtype' => 'mysql',
  'version' => '10.0.3.3',
  'dbname' => 'clouddb',
  'dbhost' => 'databaseserver',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'xxxxxxxxxxxxxxxxxx',
  'dbpassword' => 'xxxxxxxxxxxxxxxxxx',
  'installed' => true,
  'mail_domain' => '@xxxxxx.com',
  'mail_from_address' => 'xxxxxxxxxx',
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'tls',
  'mail_smtphost' => 'xxxxx.xxxxx.com',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => x,
  'mail_smtpport' => 'xxx',
  'forcessl' => true,
  'mail_smtpname' => 'xxxxxxxx@xxxxxxx.com',
  'mail_smtppassword' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
  'loglevel' => 3,
  'logfile' => '/var/log/owncloud.log',
  'logtimezone' => 'America/Toronto',
  'log_rotate_size' => 4194304,
  'maintenance' => false,
  'secret' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx',
  'theme' => '',
  'filelocking.enabled' => 'true',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.locking' => '\\OC\\Memcache\\APCu',
  'overwriteprotocol' => 'https',
  'session_lifetime' => 3600,
  'session_keepalive' => false,
  'updatechecker' => false,
  'trashbin_retention_obligation' => 'auto',
);

Are you using external storage, if yes which one: local/smb/sftp/...
yes, NFS mount from a Freenas machine

Are you using encryption: yes/no
No

Are you using an external user-backend, if yes which one:
No

`

Client configuration

Browser:
Firefox 55 & Chrome 44

Operating system:
Linux Mint/Windows 7

Anybody can help me I would appreciate. What I thought would be a quick update is turning to be a lot more extensive that I had expected.

Thanks!

There you have the problem. This can also be the cause of the performance problems. I suggest to fix this first and recheck.

Hello jvillafanez

I added some relevant information in the original post, and you may have missed it.

Basically, my php.ini has the following line in it:

open_basedir = "/var/log/:/var/www/html/:/tmp/:/mnt/data/:/dev/urandom"

AFAIK this should allow php to write in /var/log ?

To be sure it wasnt a permission issue, I have moved the log file to /var/log/httpd where the existing apache logs are, but the logfile is still not used by OC.

Anyways the log files in /var/log/httpd have the following perms:

-rw-r--r-- 1 root root 4209 Oct 21 13:26 access_log
-rw-r--r-- 1 root root 6600 Oct 21 13:22 error_log
-rw-r--r-- 1 root root 0 Oct 14 17:30 owncloud.log
-rw-r--r-- 1 apache apache 15247 Oct 8 16:51 php_errors
-rw-r--r-- 1 root root 0 Aug 15 2016 ssl_access_log
-rw-r--r-- 1 root root 0 Aug 15 2016 ssl_error_log
-rw-r--r-- 1 root root 234931 Oct 21 13:26 ssl_request_log

Which IMO should allow apache to use owncloud.log.....

I even modified the open_basedir directive in php.ini to

open_basedir = "/var/log/httpd/:/var/www/html/:/tmp/:/mnt/data/:/dev/urandom"

Still no champagne..

Only root can write...

OK fixed the perms:

-rw-r--r-- 1 apache apache 0 Oct 14 17:30 /var/log/httpd/owncloud.log

Weird because the log files in /var/log/httpd HAD all the same user/perms and apache could write to the others but not owncloud.log.

Now I assigned "apache:apache" to all log files, apache still can write to all logs except owncloud.log. Basically, that changed nothing.

jvillafanez, when you mentioned "I suggest to fix this first" how do you suggest to fix this? Do you mean that I shouldnt be using "open_basedir restrictions" in the first place?

Are you sure you're editing the right php.ini file? The error says a different thing...

Where in the error do you see that its not using /etc/php.ini AFAIK there is ONLY one php.ini in my VPS and its being used by Apache (/etc/php.ini)...

The log snipped doesn't show which php.ini is loaded. But i think it clearly shows that your PHP environment is not correctly configured to include the /var/log within the open_basedir:

open_basedir restriction in effect. File(\/var\/log) is not within the allowed path(s): (\/var\/www\/html\/:\/tmp\/:\/mnt\/data\/:\/dev\/urandom) at \/var\/www\/html\/owncloud\/lib\/private\/Log\/Owncloud.php#55"}

I think its also a quite better approach to not use such hardenings until everything is running like it should. Afterwards new hardenings could be applied step by step.

OK I managed after a while to find these errors in the apache logs:

in /var/log/httpd/php_errors

[03-Dec-2017 00:18:07 UTC] PHP Warning:  require_once(): open_basedir restriction in effect. File(/usr/share/pear/pearcmd.php) is not within the allowed path(s): (/var/log/httpd/:/var/www/html/:/tmp/:/mnt/data/:/dev/urandom) in /usr/share/pear/peclcmd.php on line 31
[03-Dec-2017 00:18:07 UTC] PHP Warning:  require_once(/usr/share/pear/pearcmd.php): failed to open stream: Operation not permitted in /usr/share/pear/peclcmd.php on line 31
[03-Dec-2017 00:18:07 UTC] PHP Fatal error:  require_once(): Failed opening required 'pearcmd.php' (include_path='/usr/share/pear:/usr/share/pear') in /usr/share/pear/peclcmd.php on line 31

in /var/log/httpd/error_log

[Sat Dec 02 21:17:58.247970 2017] [core:notice] [pid 11963] AH00052: child pid 11964 exit signal Segmentation fault (11)
[Sat Dec 02 21:17:58.248047 2017] [core:notice] [pid 11963] AH00052: child pid 11966 exit signal Segmentation fault (11)
[Sat Dec 02 21:17:59.255186 2017] [core:notice] [pid 11963] AH00052: child pid 11965 exit signal Segmentation fault (11)
[Sat Dec 02 21:17:59.255338 2017] [core:notice] [pid 11963] AH00052: child pid 11967 exit signal Segmentation fault (11)
[Sat Dec 02 21:18:14.287865 2017] [core:notice] [pid 11963] AH00052: child pid 11979 exit signal Segmentation fault (11)

Would it be possible that PHP crashes causing the issues I am having? I'm having all kind of problems with page displaying, timeouts, blank pages but a refresh always brings back the page as expected so apache is not crashing in my opinion.

Yes, i think if the webserver / apache is running unstable and is crashing you will face all kind of strange problems.