Internal Server Error (error 500) after upgrade to

Nextcloud version (eg, 12.0.2):
Operating system and version (eg, Ubuntu 17.04): Debian GNU/Linux 9
Apache or nginx version (eg, Apache 2.4.25): Apache 2.4.25
PHP version (eg, 7.1): 7.3

The issue you are facing:

My Nextcloud installation has been working fine since NC->13 NC15 -> NC16 -> NC17 -> NC18.0.1. It is set to channel “Stable”. I received an update notification so I went ahead with web based update. That however failed so I ran the update from CLI and it did throw a number of strange database errors but I manually changed the database columns it was finding to have already existing and then it went well. This was yesterday. I then restarted my instance and all was good and my instance appeared to have updated to the latest version. However, when I tried logging in this morning I started getting the following error:

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.

So I searched on forum and github, tried a number of things including but not limited to:

  1. maintenance:repair
  2. upgrade
  3. restarted the server a number of times
  4. checked the nextcloud.logs - server logs - Nothing here at all
  5. enabled debug mode -some level 3 errors but nothing relevant to the internal server error.
  6. Tried after disabling the mecached as per another post on this forum
  7. checked the disk space - There is plenty 10 Gig
  8. changed the mariadb.service as per this post
  9. checked the apache server logs - again nothing here - not even the log for screen refresh on browser where it throws same error as shown above.

The config.php is the same I have been using for previous installs and output of occ config:list system is as shown below:

    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***",
            "***REMOVED SENSITIVE VALUE***",
            "***REMOVED SENSITIVE VALUE***"
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "http:\/\/localhost",
        "htaccess.RewriteBase": "\/",
        "dbtype": "mysql",
        "version": "",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "maintenance": false,
        "theme": "",
        "loglevel": 2,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_smtpauthtype": "LOGIN",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpsecure": "tls",
        "": "stable",
        "mail_sendmailmode": "smtp",
        "mysql.utf8mb4": true,
        "data-fingerprint": "d40a41c54c9f127f40aca64874ef9fdd"

I have basically ran out of ideas on what else to troubleshoot and hence this cry for help.

Is this the first time you’ve seen this error? (Y/N): Yes. Although I have had a few issues before but none where existing posts did not already have a solution or hint that helped me resolve my issue.

Steps to replicate it:

I do not have any idea how or why it happened. All I know is that everything was working fine until the upgrade from 18.0.1 to

The output of your Nextcloud log in Admin > Logging:

index: args at /var/www/nextcloud/apps/logreader/lib/Log/Formatter.php#58","userAgent":"--","version":""}
Expected parameter 2 to be an array, null given at 
Invalid arguments passed at /var/www/nextcloud/apps/logreader/lib/Log/Formatter.php#60","userAgent":"--","version":""}
Expected parameter 2 to be an array, null given at 
Invalid arguments passed at /var/www/nextcloud/apps/logreader/lib/Log/Formatter.php#69","userAgent":"--","version":""}
by zero at /var/www/nextcloud/config/config.php#14","userAgent":"--","version":""}

For above errors - Like I said only Level 3 entries and some of them are from what changes I have mentioned I was doing to see if they fix the issue. Nothing else is in there that makes much sense with regards to the “Internal Server Error” issue.

The output of your Apache system log in /var/log/apache2/error.log:

[Fri Mar 06 17:42:43.483434 2020] [php7:warn] [pid 10421] [client ###########] PHP Warning:
A non-numeric value encountered in /var/www/nextcloud/config/config.php on line 14 

[Fri Mar 06 17:42:43.483441 2020] [php7:warn] [pid 10421]
[client ###########] PHP Warning: A non-numeric value encountered in /var/www/nextcloud/config/config.php on line 14 

[Fri Mar 06
17:42:43.483447 2020] [php7:warn] [pid 10421] [client ###########] PHP Warning: Division by zero in /var/www/nextcloud/config/config.php on
line 14

Thing is these errors were only there because while making changes on config.php to add the line "htaccess.RewriteBase": "\/", I copy pasted from browser and it took incorrect quote which caused server to show above errors but before that there were only logs for core notice and such like so:

[Fri Mar 06 06:25:10.726460 2020] [mpm_prefork:notice] [pid 25795] AH00163: Apache/2.4.25 (Debian) OpenSSL/1.0.2u configured -- resuming normal

[Fri Mar 06 06:25:10.726497 2020] [core:notice] [pid 25795] AH00094: Command line: '/usr/sbin/apache2' 

[Fri Mar 06 14:08:12.263209 2020]
[mpm_prefork:notice] [pid 25795] AH00169: caught SIGTERM, shutting down 

[Fri Mar 06 14:08:12.449866 2020] [mpm_prefork:notice] [pid 16928] AH00163:
Apache/2.4.25 (Debian) OpenSSL/1.0.2u configured -- resuming normal operations 

[Fri Mar 06 14:08:12.449990 2020] [core:notice] [pid 16928] AH00094:
Command line: '/usr/sbin/apache2' 

Interestingly, the android client seems to be connecting to the instance without any problem.

Mind to check the logfile in data directly without the log reader?

I checked it directly only. Using the command on terminal like so:

nano /var/www/nextcloud/data/nextcloud.log

Use tail -f instead of nano and try to login. Check what errors is printed.

tried that now… nothing happened. No addition to the log it is still showing the last entry from 17:41 (It is 19:15 right now).

tail -f /var/www/nextcoud/data/nextcloud.log

Last Entry before and after the attempt to reload the page at 19:15 local time:

{"reqId":"kt9RSX78SWGoCmeb7GNB","level":3,"time":"2020-03-06T17:41:29+00:00","remoteAddr":"","user":"--","app":"PHP","method":"","url":"--","message":"Division by zero at /var/www/nextcloud/config/config.php#14","userAgent":"--","version":""}

Actually I have just managed to fix my problem. I was thinking of what all I did since yesterday and realised that after NC was working fine I updated the system and ran autoremove. Now in doing so the CLI php was updated to 7.4 and autoremove then removed some of the php7.3 components which caused all the havoc. For anyone else who might be facing the same issue, the steps to fix will be:

Get the list of packages that were autoremoved using the following command:

zgrep -E "^(Remove:|Purge)" /var/log/apt/history.log*

Now you should see some output like this:

/var/log/apt/history.log:Remove: php7.3-xml:amd64 (7.3.15-4+0~20200224.55+debian9~1.gbpbea824), php7.3-zip:amd64 (7.3.15-4+0~20200224.55+debian9~1.gbpbea824), php7.3-mbstring:amd64 (7.3.15-4+0~20200224.55+debian9~1.gbpbea824), sgml-base:amd64 (1.29), php7.0-gd:amd64 (7.0.33-25+0~20200225.32+debian9~1.gbpa11893), libicu64:amd64 (64.1-0.1+0~20190410090943.5+stretch~1.gbp38f694), php7.3-mysql:amd64 (7.3.15-4+0~20200224.55+debian9~1.gbpbea824), php7.3-gd:amd64 (7.3.15-4+0~20200224.55+debian9~1.gbpbea824), php7.3-curl:amd64 (7.3.15-4+0~20200224.55+debian9~1.gbpbea824), php7.3-intl:amd64 (7.3.15-4+0~20200224.55+debian9~1.gbpbea824), xml-core:amd64 (0.17), php7.0-mbstring:amd64 (7.0.33-25+0~20200225.32+debian9~1.gbpa11893), php7.0-curl:amd64 (7.0.33-25+0~20200225.32+debian9~1.gbpa11893), php7.0-zip:amd64 (7.0.33-25+0~20200225.32+debian9~1.gbpa11893), php7.0-intl:amd64 (7.0.33-25+0~20200225.32+debian9~1.gbpa11893), php7.0-mysql:amd64 (7.0.33-25+0~20200225.32+debian9~1.gbpa11893)
/var/log/apt/history.log.10.gz:Remove: linux-headers-4.9.0-6-amd64:amd64 (4.9.88-1+deb9u1), linux-image-4.9.0-6-amd64:amd64 (4.9.88-1+deb9u1), linux-headers-4.9.0-6-common:amd64 (4.9.88-1+deb9u1)
/var/log/apt/history.log.4.gz:Remove: linux-headers-4.9.0-8-amd64:amd64 (4.9.144-3), linux-headers-4.9.0-8-common:amd64 (4.9.144-3), linux-image-4.9.0-8-amd64:amd64 (4.9.144-3)

Take out the php7.3 related packages and add to apt install command below:

sudo apt install xml-core php7.3-xml php7.3-zip php7.3-mbstring php7.3-mysql php7.3-gd php7.3-curl php7.3-intl

Then restart your server for good measure:

sudo systemctl restart apache2
1 Like

I faced this behaviour too after upgrade to PHP7.4!

In my case it was only the configuration mentioning ```

“memcache.local”: “\OC\Memcache\APCu”,

In PHP7.4 the APCu is not available (here with Debian Bullseye) if you comment out this line, or  change it to

"memcache.local": "\\OC\\Memcache\\Redis",

(suppose you have Redis installed) nearly everything works fine - except the Mail-App which does not find any IMAP-Account!
Greetz robw
1 Like

Worked for me on Debian Bullseye as a temporary solution.

None of the mentioned solutions are working for me, and I’m about ready to give up.

I also had this issue when updating the Debian Bullseye.
Using pubmania’s commandzgrep -E "^(Remove:|Purge)" /var/log/apt/history.log* to find old php7.3 mods that were uninstalled and re-installing the 7.4 versions worked for me.
When you reinstalled your mods did you ensure to restart the web server service?