Can't login after upgrade and server change - high CPU-load (100%)

I changed the server, because I get an error message (PHP5.6 is not…).
After upgrade is done, I can not login.
occ on comand line (with PHP7.0 works). therefore I disabled all apps, but no change.

Expected behaviour

Login to see dashboard.

Actual behaviour

Browser load infinite. Login screen displayed. High server-CPU-load (100%).

Server configuration

Operating system: Debian 9.8

Web server: Apache 2.4

Database: MariaDB 10.1.38

PHP version: FCGI 7.0, 7.1, 7.2

ownCloud version: config file:

Updated from an older ownCloud or fresh install: update from 10…

List of activated apps: all disabled.

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


Web server error log

nor error, just hanging fcgi-process.


did you follow the doc and disabled all the apps before doing the upgrade ? Did the upgrade process ended up fine ? Do you have the log of the upgrade ?
Could you restart the PHP FCGI and retry the login page ? (if not already tried) Btw which PHP version do you really use, you talk about 7.0, 7.1, 7.2 it’s not clear to me, I might say 7.0 since it’s the one for your cli.

1 Like

I disabled the apps after upgrade was done.
The upgrade process ended fine. No errors.
There is an data/update.log, but with no errors.
I restarted the FCGI service 3-4-times and tried it again. Switched the PHP-versions, restarted and tried again and again. Same problem all the time: browser wouldn’t load after login-form.

before disabling:

  • calendar: 1.6.3
  • comments: 0.3.0
  • configreport: 0.2.0
  • contacts: 1.5.5
  • dav: 0.4.0
  • federatedfilesharing: 0.4.0
  • federation: 0.1.0
  • files: 1.5.2
  • files_external: 0.7.1
  • files_pdfviewer: 0.11.0
  • files_sharing: 0.11.0
  • files_trashbin: 0.9.1
  • files_versions: 1.3.0
  • files_videoplayer: 0.10.1
  • firstrunwizard: 1.2.0
  • gallery: 16.1.1
  • market: 0.5.0
  • notifications: 0.5.0
  • provisioning_api: 0.5.0
  • systemtags: 0.3.0
  • updatenotification: 0.2.1
  • encryption
  • external
  • user_external

Alright, could you try enabling more verbose logging ?
Did you check the error log of your webserver too ?
Did you try from different browser ?

Thanks for your quick response!
I enabled it and renamed the old data/owncloud.log. But after try to login, there is no new logfile.

The apache error.log just says:

[Fri Aug 23 12:13:42.443976 2019] [fcgid:warn] [pid 104266] [client MyIP:58878] mod_fcgid: read data timeout in 600 seconds
[Fri Aug 23 12:13:42.444051 2019] [core:error] [pid 104266] [client MyIP:58878] End of script output before headers: index.php

Tested it with Safari and Chrome. Same problem. :cry:

btw: the login-site appears instantly.


i’m not sure if this is relevant but from what i have read in the past ownCloud only supports Apache with mod_php officially:

and lists nginx with php-fpm as an alternative but unsupported option:

Personally i’m using the alternative option with nginx and php-fpm and haven’t found any issues with that setup yet.

1 Like

Changed permissions on files and folders and activated mod_php: same problem. wtf?

Are there any caching files or someting else?

Alright, well don’t you have opcache or any PHP opcode activated ?
Could you try to create a test.php file with a phpinfo and try to load it ?
Is your database configuration correct ? Could you paste your config.php (anonymize it) ?


Memcached ist active.
Other PHP-files loads very quickly. (phpinfo() was my first try in the morning.) owncloud-start site is loading quickly too. Only the login sequence stuck.

$CONFIG = array (
  'instanceid' => '51a08b73cc2e8',
  'passwordsalt' => 'XXXX',
  'datadirectory' => '/var/www/',
  'dbtype' => 'mysql',
  'version' => '',
  'dbname' => 'c1_cloud',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'c1_cloud',
  'dbpassword' => 'xxx',
  'installed' => true,
  'forcessl' => true,
  'maintenance' => false,
  'trusted_domains' =>.
  array (
    0 => 'localhost',
    1 => '',
  'secret' => 'xxx',
  'theme' => '',
  'loglevel' => 4,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcached_servers' =>.
  array (
    0 =>.
    array (
      0 => 'localhost',
      1 => 11211,
  'cache_path' => '',
  'trashbin_retention_obligation' => 'auto',
  'appstore.experimental.enabled' => true,
  'mail_domain' => '',
  'mail_from_address' => 'noreply',
  'mail_smtpmode' => 'php',
  'updater.secret' => 'xxx',
  'log_type' => 'owncloud',
  'logfile' => 'owncloud.log',
  'loglevel' => '3',
  'logdateformat" => "F d, Y H:i:s',

Could this be an PHP session related issue similar to:


Maybe there are some permission issues on the new server where PHP isn’t able to write the session required for the login? Or there are additional permission issues after the server change which could explain why the owncloud.log isn’t written anymore?


Try removing anything “useless” things from your config.php such as the memcache to keep it simple to debug.
The database connection works ?
Careful you have two times the loglevel, set it to 0 or 1, something very verbose.

As I said before: “I changed the permissions…”, because there was an error of the session_path. Sorry for the short answer!

Removing other config didn’t solve, but the logfile now apears!! (I think it was the double “loglevel”!)

Thousends of entries appear with the same error:

{“reqId”:“XRCL9hJElGp3FOVmYasz”,“level”:3,“time”:“2019-08-23T12:38:11+00:00”,“remoteAddr”:“MyIP”,“user”:“”,“app”:“PHP”,“method”:“POST”,“url”:"/index.php/login",“message”:“realpath(): open_basedir restriction in effect. File(/) is not within the allowed path(s): (/var/www/clients/client1/web66/cloud:/var/www/clients/client1/web66/private:/var/www/clients/client1/web66/tmp:/var/www/ at /var/www/clients/client1/web66/cloud/lib/private/Files/Storage/Local.php#389”}

It seems to be a wrong rewrite rule?

ahaha no it’s “easier”, you must have set the open_basedir somewhere in your php configuration, could you find it and comment it temporary to check if your ownCloud works fine after.
It’s possible you have to some RewriteBase somewhere that would mess it up.

1 Like

With open_basedir("/:/…) I can login! omfg!
But this should not be used.
How can I fix this?

ahah I was sure, well could you check you have a RewriteBase somewhere in your .htaccess or Apache configuration ?

1 Like

There is no RewriteBase.

Alright, do you have any mount bind, symbolic link, selinux or secure policies anywhere ?
I’m guessing you are using a panel such as cpanel or ispconfig.
There is maybe some kind of chrooting done by the panel.


Hey yes, it’s ispconfig. But there is no chroot, mount bind or symbolic link.

I got it!
The home-path changed! I manually edit this in oc_accounts and correct the open_basedir again (with no “/”). And it works!!

ahah nicely done :slight_smile:
It’s weird it has changed, you might consider doing a thorough check of everything on your ownCloud now.
I’m glad it’s fixed, think about solving the topic please.