Internal server error when trying to login

Nextcloud version : 20.0.0-1
Operating system and version : Arch Linux
Apache or nginx version (eg, Apache 2.4.25): Apache 2.4.46-2
PHP version : 7.4.11-1

The issue you are facing:

After upgrading from NC 19 to NC 20, all clients face login problems. Web login results in message: Internal server error. Desktop clients report “Server is temporary unavailable”. I’ve tried other accounts with similar results. Before the upgrade, all clients were able to login without any issues.

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

Steps to replicate it:

  1. Upgrade from NC 19 to NC 20.
  2. Login using the web interface

The output of your Nextcloud log in Admin > Logging:

https://pastebin.com/ebA2b4rd

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

<?php
$CONFIG = array (
  'instanceid' => 'XXXXXXXXXXX',
  'passwordsalt' => 'XXXXXXXXXXXXXXX',
  'secret' => 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',
  'trusted_domains' => 
  array (
    0 => 'owncloud.uv.vlegel.net',
    1 => 'vlegelwolk.uv.vlegel.net',
  ),
  'datadirectory' => '/srv/http/owncloud/data',
  'overwrite.cli.url' => 'https://vlegelwolk.uv.vlegel.net',
  'overwriteprotocol' => 'https',
  'dbtype' => 'mysql',
  'version' => '20.0.0.9',
  'dbname' => 'owncloud',
  'dbhost' => 'sun.uv.vlegel.net',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'XXXXXXXXX',
  'dbpassword' => 'XXXXXXXXXXX',
  'installed' => true,
  'theme' => '',
  'maintenance' => false,
  'mail_from_address' => 'nextcloud',
  'mail_smtpmode' => 'smtp',
  'mail_domain' => 'uv.vlegel.net',
  'mail_smtphost' => 'postoffice.uv.vlegel.net',
  'mail_smtpport' => '25',
  'log_type' => 'file',
  'logfile' => '/var/log/nextcloud.log',
  'loglevel' => 0,
  'syslog_tag' => 'Nextcloud',
  'trashbin_retention_obligation' => 'auto',
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'mysql.utf8mb4' => true,
  'app_install_overwrite' => 
  array (
    0 => 'calendar',
    1 => 'drawio',
    2 => 'weather',
    3 => 'tasks',
    4 => 'carnet',
    5 => 'occweb',
    6 => 'ocr',
    7 => 'files_reader',
    8 => 'radio',
    9 => 'qownnotesapi',
    10 => 'photosphereviewer',
    11 => 'bookmarks_fulltextsearch',
  ),
  'has_rebuilt_cache' => true,
);

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

[Sun Oct 04 00:00:15.491625 2020] [ssl:warn] [pid 379] AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name
[Sun Oct 04 00:00:15.492507 2020] [lbmethod_heartbeat:notice] [pid 379] AH02282: No slotmem from mod_heartmonitor
[Sun Oct 04 00:00:15.557477 2020] [mpm_prefork:notice] [pid 379] AH00163: Apache/2.4.46 (Unix) OpenSSL/1.1.1h PHP/7.4.10 configured -- resuming normal operations
[Sun Oct 04 00:00:15.557499 2020] [core:notice] [pid 379] AH00094: Command line: '/usr/bin/httpd -D FOREGROUND'
[Sun Oct 04 06:54:41.688204 2020] [mpm_prefork:notice] [pid 379] AH00170: caught SIGWINCH, shutting down gracefully
[Sun Oct 04 06:55:12.296250 2020] [ssl:warn] [pid 385] AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name
[Sun Oct 04 06:55:12.471091 2020] [ssl:warn] [pid 385] AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name
[Sun Oct 04 06:55:12.471970 2020] [lbmethod_heartbeat:notice] [pid 385] AH02282: No slotmem from mod_heartmonitor
[Sun Oct 04 06:55:13.221485 2020] [mpm_prefork:notice] [pid 385] AH00163: Apache/2.4.46 (Unix) OpenSSL/1.1.1h PHP/7.4.11 configured -- resuming normal operations
[Sun Oct 04 06:55:13.221566 2020] [core:notice] [pid 385] AH00094: Command line: '/usr/bin/httpd -D FOREGROUND'
[Wed Oct 07 07:41:22.110678 2020] [mpm_prefork:notice] [pid 385] AH00170: caught SIGWINCH, shutting down gracefully
[Wed Oct 07 07:41:22.316197 2020] [ssl:warn] [pid 18631] AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name
[Wed Oct 07 07:41:22.355058 2020] [ssl:warn] [pid 18631] AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name
[Wed Oct 07 07:41:22.355760 2020] [lbmethod_heartbeat:notice] [pid 18631] AH02282: No slotmem from mod_heartmonitor
[Wed Oct 07 07:41:22.403701 2020] [mpm_prefork:notice] [pid 18631] AH00163: Apache/2.4.46 (Unix) OpenSSL/1.1.1h PHP/7.4.11 configured -- resuming normal operations
[Wed Oct 07 07:41:22.403757 2020] [core:notice] [pid 18631] AH00094: Command line: '/usr/bin/httpd -D FOREGROUND'
[Wed Oct 07 07:43:15.489182 2020] [mpm_prefork:notice] [pid 18631] AH00170: caught SIGWINCH, shutting down gracefully
[Wed Oct 07 07:43:15.644935 2020] [ssl:warn] [pid 18696] AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name
[Wed Oct 07 07:43:15.666090 2020] [ssl:warn] [pid 18696] AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name
[Wed Oct 07 07:43:15.666906 2020] [lbmethod_heartbeat:notice] [pid 18696] AH02282: No slotmem from mod_heartmonitor
[Wed Oct 07 07:43:15.705229 2020] [mpm_prefork:notice] [pid 18696] AH00163: Apache/2.4.46 (Unix) OpenSSL/1.1.1h PHP/7.4.11 configured -- resuming normal operations
[Wed Oct 07 07:43:15.705303 2020] [core:notice] [pid 18696] AH00094: Command line: '/usr/bin/httpd -D FOREGROUND'

Please let me know how I can help solving this problem. Thank you in advance for your efforts.

I have the same issue. Watchtower upgraded the apache docker image and now I cannot login, and my folders get HTTP 503. I also cannot go back to 19.0 because my data is now at 20.0 and downgrade is not supported. My Nextcloud is completely unusable now. Please advise on a fix for this. The docker image was the only change.

Same situation on my docker host and on the host of my friend: Automatic update via Watchtower - now both showing Internal server error.

bump. Any suggestions here to get Nextcloud back online after the update?

Welcome to the Nextcloud community! @redtux @Iceman123 @owenja6

bump. It’s been over a week with no replies from Nextcloud. Please help getting our environments working again. At the moment, we cannot use Nextcloud and it’s plugin features.

Found another issue which provides a workaround: "Could not decrypt key" upon login

I took a look at that, but I have never enabled encryption in my implementation and so the key files and directory structure do not exist:

root@0e2dbc9639c2:/var/www/html# find . -name OC_DEFAULT_MODULE
root@0e2dbc9639c2:/var/www/html#

Have you tried to reset the password for one user? Does the login work after a password reset?
I don’t know your configuration setup, but are you sure /var/www/html is the top tree where nextcloud is storing it’s data (a.k.a. datadirectory contains /var/www/html in the config.php?

Thanks for responding @redtux. I am using the Docker image, so everything is under /var/www/html. My user data is a Docker Volme (CIFS mount) that is mounted on /var/www/html/data in the container. All my users, except admin, are authenticated via Active Directory.

Would you mind running occ log:watch and attempt a login in order to capture what NC thinks what goes wrong? I’m not a member of the NC dev team, but perhaps I can help getting your environment back to a working state.

Sooo…it appears that there is an error running OCC:

$ docker exec --user www-data nextcloud php occ
An unhandled exception has been thrown:
Error: Interface ‘OCA\Files_External\Lib\Config\IBackendProvider’ not found in /var/www/html/custom_apps/files_external_gdrive/lib/AppInfo/Application.php:32
Stack trace:
#0 /var/www/html/lib/composer/composer/ClassLoader.php(444): include()
#1 /var/www/html/lib/composer/composer/ClassLoader.php(322): Composer\Autoload\includeFile(’/var/www/html/c…’)
#2 [internal function]: Composer\Autoload\ClassLoader->loadClass(‘OCA\Files_exter…’)
#3 [internal function]: spl_autoload_call(‘OCA\Files_exter…’)
#4 /var/www/html/lib/private/AppFramework/Bootstrap/Coordinator.php(108): class_exists(‘OCA\Files_exter…’)
#5 /var/www/html/lib/base.php(645): OC\AppFramework\Bootstrap\Coordinator->runRegistration()
#6 /var/www/html/lib/base.php(1092): OC::init()
#7 /var/www/html/console.php(49): require_once(’/var/www/html/l…’)
#8 /var/www/html/occ(11): require_once(’/var/www/html/c…’)

That doesn’t sound good. Does the volume holding the data also contain custom_apps/files_external_gdrive/lib/AppInfo/Application.php? I would expect this to be separated from the user data. Like on my arch linux system, apps are part of /usr/share/webapps/nextcloud tree.

So, the custom_apps tree is under /var/www/html. On Docker, nothing is separated out. This is what is mounted in my Docker Compose file:

    volumes:
  - /data/nextcloud:/var/www/html
  - users:/var/www/html/data

Keep in mind that this has been working perfectly fine for a long time, and have had a score of A+ on securityheaders.com (using a separate Apache2 reverse proxy). The only thing that changed was that the Docker image got upgraded to 20.0, which broke it. Now that the data is at 20.0, I cannot roll back.

It’s weird that it has stopped working. Perhaps with the latest update, a security setting was triggered of which the user isn’t aware. I wish I could help solving the problem but I don’t know how yet. I’ll try to create a somewhat similar setup as you have. If possible, can you send me the docker compose file?

Thanks @redtux! I have sanitized the compose file, so it will need some editing before you test. I have my own build based on the official Nextcloud image.

I have a cron job that runs a script that checks for a new image for the apache tag of the official Nextcloud image. If it has changed, it triggers the build in my repository. My build only adds the file /usr/src/nextcloud/config/redis.config.php (below):

<?php
$CONFIG = array (
  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => array(
    'host' => 'redis',
    'port' => 6379,
  ),
);

There is also the office container that is the Collabora Core application. That integration with Nextcloud is successful, but it always threw an error when a user tried to open a file in the webui. I have tried the stack without that container and still get the same HTTP 500 error when trying to access Nextcloud.

version: '2'

services:
  db:
    image: mariadb
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    restart: unless-stopped
    container_name: mysql
    volumes:
      - /data/mysql:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=secret
      - MYSQL_PASSWORD=secret
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      

  redis:
    image: redis:alpine
    restart: unless-stopped
    container_name: redis
    volumes:
      - data:/data

  app:
    image: otispresley/nextcloud:latest
    restart: unless-stopped
    container_name: nextcloud
    ports:
      - 8080:80
    volumes:
      - /data/nextcloud:/var/www/html
      - users:/var/www/html/data
    environment:
      - MYSQL_HOST=db
      - MYSQL_PASSWORD=secret
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
    depends_on:
      - db
      - redis

  cron:
    image: otispresley/nextcloud:latest
    restart: unless-stopped
    container_name: cron
    volumes:
      - /data/nextcloud:/var/www/html
    entrypoint: /cron.sh
    depends_on:
      - db
      - redis
      
  office:
    image: collabora/code:latest
    restart: unless-stopped
    container_name: office
    ports:
      - 9980:9980
    environment:
      - domain=office\\.mydomain\\.com
    cap_add:
      - MKNOD
      
volumes:
    users:
      driver: local
      driver_opts:
         type: cifs
         device: //ip_address/Users
         o: username=myuser,password=mypass,file_mode=0770,dir_mode=0770,rw,uid=33,gid=33

A clean install based on docker works without reproducing the problem. If you inspect the //ip_address/Users/.../<user>

directory outside the container, which directories are listed under a ? A clean install only contains

cache
files

In my NC env, (most likely because I’ve enabled settings in the past) do contain a files_encryption directory.

Hi @redtux. Thanks for testing this. In the user directory for the user account I use regularly, there is cache, files, files_trashbin, files_versions, uploads. For a user that has only logged in once in the distant past, there is only cache and files.

I will do some more testing, but I did do a little over the weekend. I started up a new stack with a local volume rather than a CIFS mount and a local volume rather than the bind mounted database path. That reproduced the problem for me. Just running the nextcloud container alone worked and I was able to do initial setup and log in.