Docker upgrade -> CSRF error, then exception

ℹ️ Support
1

Nextcloud version (eg, 20.0.5): 21.3
Operating system and version (eg, Ubuntu 20.04): Debian 10.11
Apache or nginx version (eg, Apache 2.4.25): nginx/1.14.2
PHP version (eg, 7.4): php 7.3.31

The issue you are facing:

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

Steps to replicate it:

  1. Docker image for nextcloud created some months ago with simple Portainer stack, compliant with official image (Docker Hub, Base version - apache). At that time, image version was 21.3.something
  2. Nextcloud notified me of an update. I accepted and triggered the update. Unfortunately, new release was v23 and stupidly Nextcloud engaged into the upgrade process only to indicate that I cannot jump over v22! And obviously switched some bit in the database to indicate “upgrade in progress”.
  3. I then cannot cancel the upgrade process (although it’s stuck) and decided to stop both containers (nextcloud + mariaDB), remove them from the machine (keeping the stored volumes), delete the unlinked images and recreate the whole stuff in the hope that “latest” would be equal to “v23” now.
  4. Unfortunately, once both containers are recreated, event if the core nextcloud looks to be v23, connecting to the app as admin displays the “Upgrade v21 → v23 will be done” page (with a list of apps that are not supported anymore) with no choice other than “Start upgrading”.
  5. I then diligently click on Start and Nextcloud immediately returns “CSRF error, connection closed”.
  6. I try to cold-refresh the page, access to the page using its external URL (https) instead of the internal IP address and the upgrade starts repairing/upgrading the database.
  7. Once the database scheme has been upgrade, the app returns “Exception: Database error when running migration latest for app core”

The output of your Nextcloud log in Admin > Logging:

Not accessible
NC returns (sorry FR)

Préparation de la mise à jour
Réglage du niveau de journalisation à "déboguage"
Mode de maintenance activé
Étape de réparation : Repair MySQL collation
Informations de réparation : All tables already have the correct collation -> nothing to do
Étape de réparation : Repair SQLite autoincrement
Étape de réparation : Copy data from accounts table when migrating from ownCloud
Étape de réparation : Drop account terms table when migrating from ownCloud
Mise à jour du schéma de la base de données
Exception: Database error when running migration latest for app core

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

<?php
$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 => 
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),
  'instanceid' => 'instance',
  'passwordsalt' => 'pDwX+7lRy2DmTSSECKjdkC9OXHRxRp',
  'secret' => 'secret',
  'trusted_domains' => 
  array (
    0 => '192.168.1.19',
    1 => 'files.mydomain.com',
  ),
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'mysql',
  'version' => '21.0.3.1',
  'overwrite.cli.url' => 'http://192.168.1.19:8080',
  'overwriteprotocol' => 'https',
  'dbname' => 'nextcloud',
  'dbhost' => 'db',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'db-user',
  'dbpassword' => 'db-password',
  'installed' => true,
  'default_phone_region' => 'fr_FR',
  'mail_from_address' => 'mailfrom',
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_domain' => 'mydomain.com',
  'mail_smtphost' => 'smtp.myprovider.com,
  'mail_smtpport' => '465',
  'mail_smtpauth' => 1,
  'mail_smtpname' => 'smtpname',
  'mail_smtppassword' => 'smtppassword',
  'mail_smtpsecure' => 'ssl',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'updater.secret' => 'updater-secret',
);

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

No error

I only have two sleepy accounts on the server, so maybe I could just wipe everything (but the files), recreate the Docker containers and let NC create a fresh index of the files: what’s your advice?

Thanks in advance for any help!