Nextcloud-Tabelle oc_filecache_extended korrupt

Hallo zusammen,
seit Tagen versuche ich ein Problem zu lösen, bei dem ich nicht weiterkomme.

Debian 6.1.0-0.deb11.21-amd64
OMV 6.9.16-1 (Shaitan)
Docker unter OMV
Nextcloud - neueste Update durchgeführt

Vor zwei Jahren habe ich ein NAS aufgesetzt, bei dem jetzt kurz vor Garantieende der Rechner sich plötzlich und ohne Vorwarnung verabschiedet hat.
Kopie des Rechners erstellt und auf einen Rechner gleicher Bauart übertragen.

Es hat fast alles funktioniert: debian/OMV läuft. Nextcloud läuft nicht.

Bei der Ursachenforschung habe ich herausgefunden, dass die Tabellen oc_filecache und oc_filecache_extended zuerschossen wurden. Jetzt hängt die Anmeldung an Nextcloud direkt nach der Anmeldung in einer Fehlermeldung

"

Interner Serverfehler

Der Server konnte die Anfrage nicht fertig stellen.

Sollte dies erneut auftreten, sende bitte die nachfolgenden technischen Einzelheiten an deine Serveradministration.

Weitere Details können im Serverprotokoll gefunden werden.

Technische Details

  • Entfernte Adresse: 84.XXX.XXX.XXX
  • Anfragekennung: McV2loovGtlIC1w7frax
    "
    Ich führe in diesem Falle diese Fehlermeldung auf die korrupten Tabellen zurück.

Über mariadb konnte ich die oc_filecache-Tabelle neu aufsetzen, da im Netz die SQL-Struktur zu finden war. Für die oc_filecache_extended konnte ich nichts dergleichen finden.

Um an die Tabelle heranzukommen, habe ich auf einem überzähligen Laptop versucht, die gleiche Installation aufzusetzen. Nach mehrmaligen Versuchen bin ich immer bis an die Stelle gekommen, wo ich Docker installiert habe und die Nextcloud folgen müsste. Leider kann ich Nextcloud nicht starten, ich lande immer auf der SWAG-Seite von NGINX.

Meine Fragen sind jetzt:
→ Wie komme ich an die SQL-Tabellenstruktur, um sie neu aufsetzen zu können

falls das nicht klappt/funktioniert:
→ Was mache ich bei der neuen Installation falsch, dass ich nach der Installation (nach Anleitung) nicht auf Nextcloud komme?

Falls ich hier gegen Konvetionen verstoße: Ich bin hier neu und mache es nicht absichtlich. Dann bitte melden.
Uwe

MariaDB [nextcloud]> describe oc_filecache_extended;
+---------------+---------------------+------+-----+---------+-------+
| Field         | Type                | Null | Key | Default | Extra |
+---------------+---------------------+------+-----+---------+-------+
| fileid        | bigint(20) unsigned | NO   | PRI | NULL    |       |
| metadata_etag | varchar(40)         | YES  |     | NULL    |       |
| creation_time | bigint(20)          | NO   | MUL | 0       |       |
| upload_time   | bigint(20)          | NO   | MUL | 0       |       |
+---------------+---------------------+------+-----+---------+-------+
4 rows in set (0.001 sec)
1 Like

Hallo j-ed,
vielen Dank für die schnelle Antwort: Leider Fehlanzeige. Das Ergebnis sieht so aus:

Für mich wäre eine CREATE TABLE ‘oc_filecache_extended’ wie hier für die oc_filecache gepostet

interessant bzw. damit habe ich die oc_filecache reparieren können.

Ich denke, eine leere oc_filecache_extended.idb wäre ebenfall brauchar, damit könnte ich die korrupte Datei überschreiben.

Danke für die Hilfe
Uwe

Jetzt habe ich zu schnell geantwortet :wink:
Ich bin nicht der große Shell-Freund, ich arbeite lieber mit einer GUI.
Wie kann ich aus der mit describe erzeugten Darstellung einen sql-Befehl erzeugen, um die Tabelle zu erstellen?
Uwe

@siedi102
bei mir sehen die create befehle so aus

SHOW CREATE TABLE `oc_filecache`;

und

SHOW CREATE TABLE `oc_filecache_extended`;

Ausgabe:

CREATE TABLE `oc_filecache` (
  `fileid` bigint NOT NULL AUTO_INCREMENT,
  `storage` bigint NOT NULL DEFAULT '0',
  `path` varchar(4000) COLLATE utf8mb4_bin DEFAULT NULL,
  `path_hash` varchar(32) COLLATE utf8mb4_bin NOT NULL DEFAULT '',
  `parent` bigint NOT NULL DEFAULT '0',
  `name` varchar(250) COLLATE utf8mb4_bin DEFAULT NULL,
  `mimetype` bigint NOT NULL DEFAULT '0',
  `mimepart` bigint NOT NULL DEFAULT '0',
  `size` bigint NOT NULL DEFAULT '0',
  `mtime` bigint NOT NULL DEFAULT '0',
  `storage_mtime` bigint NOT NULL DEFAULT '0',
  `encrypted` int NOT NULL DEFAULT '0',
  `unencrypted_size` bigint NOT NULL DEFAULT '0',
  `etag` varchar(40) COLLATE utf8mb4_bin DEFAULT NULL,
  `permissions` int DEFAULT '0',
  `checksum` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL,
  PRIMARY KEY (`fileid`),
  UNIQUE KEY `fs_storage_path_hash` (`storage`,`path_hash`),
  KEY `fs_parent_name_hash` (`parent`,`name`),
  KEY `fs_storage_mimetype` (`storage`,`mimetype`),
  KEY `fs_storage_mimepart` (`storage`,`mimepart`),
  KEY `fs_storage_size` (`storage`,`size`,`fileid`),
  KEY `fs_parent` (`parent`),
  KEY `fs_name_hash` (`name`),
  KEY `fs_mtime` (`mtime`),
  KEY `fs_size` (`size`),
  KEY `fs_storage_path_prefix` (`storage`,`path`(64)),
  KEY `memories_parent_mimetype` (`parent`,`mimetype`)
) ENGINE=InnoDB AUTO_INCREMENT=448 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

und

CREATE TABLE `oc_filecache_extended` (
  `fileid` bigint unsigned NOT NULL,
  `metadata_etag` varchar(40) COLLATE utf8mb4_bin DEFAULT NULL,
  `creation_time` bigint NOT NULL DEFAULT '0',
  `upload_time` bigint NOT NULL DEFAULT '0',
  PRIMARY KEY (`fileid`),
  KEY `fce_ctime_idx` (`creation_time`),
  KEY `fce_utime_idx` (`upload_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

Hallo zomtec2311,
mit
SHOW CREATE TABLE oc_filecache_extended;

erhalte ich die Fehlermeldung, dass die Tabelle korrupt ist.

Ich habe die Tabelle auch mit

CREATE TABLE oc_filecache_extended_a LIKE oc_filecache_extended

versucht zu kopieren. Da erhalte ich auch Fehlermeldungen, da dieser Befehl anscheinend eine leere Kopie des Originals (also der korrupten Tabelle) anfertigt.

Jetzt versuche ich mal mit Deiner SQL-Ausgabe, also dem CREATE TABLE …, die Tabelle neu zu erstellen. Mal sehen ob das auch so einfach geht, wie es bei der oc_filecache-Tabelle gegangen ist.

Auf alle Fälle schon mal vielen Dank für Eure Hilfe. Sollte es mir gelingen, die Tabelle zu reparieren, melde ich mich mit dem Ablauf dazu hier.

Uwe