Update failed and now web only shows Internal Server Error has occurred

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5): 23.0.2
Operating system and version (eg, Ubuntu 20.04): Centos 8.2
Apache or nginx version (eg, Apache 2.4.25): Apache
PHP version (eg, 7.4): 7.4.13

The issue you are facing:

Upgraded from 21.0.4 > 21.0.9 Sync to clients OK but web says “Internal Server Error has occurred”. Continued to upgrade to 22.2.5 and then 23.0.2 - same web error. Noted on comparison to working server, that “index.php” missing from web url ?

Is this the first time you’ve seen this error? (Y/):Y

Steps to replicate it:

  1. Upgraded using updater/updater.phar

The output of your Nextcloud log in Admin > Logging:

Cannot Access

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'passwordsalt' => '<REMOVED>',
  'secret' => '<REMOVED>',
  'trusted_domains' =>
  array (
    0 => 'pcloud.pirtek.com.au',
    1 => 'pcloud2.pirtek.com.au',
  ),
  'datadirectory' => '/pCLOUDdata',
  'dbtype' => 'mysql',
  'version' => '23.0.2.1',
  'overwrite.cli.url' => 'http://pcloud.pirtek.com.au/nextcloud',
  'htaccess.RewriteBase' => '/nextcloud',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'oc_pCLOUDAdmin',
  'dbpassword' => '<REMOVED>',
  'installed' => true,
  'instanceid' => 'oc1rl5m3dmfd',
  'mail_from_address' => 'pCLOUDAdmin',
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_domain' => 'pirtek.com.au',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_smtphost' => 'notes.pirtek.com.au',
  'mail_smtpport' => '25',
  'mail_smtpname' => '<REMOVED>',
  'mail_smtppassword' => '<REMOVED>',
  'trashbin_retention_obligation' => '30, 35',
  'logfile' => '/var/log/nextcloud/nextcloud.log',
  'loglevel' => 0,
  'logdateformat' => 'F d, Y H:i:s',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'redis' =>
  array (
    'host' => '/var/run/redis/redis.sock',
    'port' => 6379,
  ),
  'twofactor_enforced' => 'false',
  'twofactor_enforced_groups' =>
  array (
    0 => 'Pirtek IT',
  ),
  'twofactor_enforced_excluded_groups' =>
  array (
    0 => 'admin',
  ),
  'maintenance' => false,
  'theme' => '',
  'default_phone_region' => 'AU',
);


The output of your Apache/nginx/system log in /var/log/____:

[Thu Mar 10 17:39:26.525196 2022] [core:error] [pid 1047930:tid 139731316762368] [client 192.168.3.1:59376] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

Sorry no real idea. But can you execute this command in shell and the correct path /path/to/nextcloud? Sometimes we get additional errors.

php index.php

OK so I started looking into the .htaccess file(s) and found each one in the backup folder increased with each version upgrade.
I checked the .htaccess folder on my home (working) environment and found that below the line that says #### DO NOT CHANGE ANYTHING ABOVE THIS LINE #### there were only 2 lines (on working server) and MANY lines on NON working server.

I deleted all the lines below :slight_smile:
ErrorDocument 403 /nextcloud/
ErrorDocument 404 /nextcloud/

Restared Apache and Voila ! it is alive again.

Not sure how / why these lines of code were introduced and why post upgrade they failed, but right now - working successfully on 23.0.2 on Rocky Linux 8.5

Very happy !

1 Like

Thank you for this. I had the same issue and you saved me.