Hallo zusammen,

ich brauche Hilfe bei der Wiederherstellung meiner alten Nextcloud‑Installation auf Unraid.

Ausgangslage:

• Unraid Version: 7.2.3

• Nextcloud lief früher als Docker‑Container mit Image: lscr.io/linuxserver/nextcloud

• Nach einer Störung war der alte Container weg, ich habe Nextcloud vorübergehend außerhalb von Docker genutzt.

• Jetzt möchte ich wieder zurück zur Docker‑Variante mit dem linuxserver/nextcloud‑Image, die alten Daten und die alte Datenbank sollen weiterverwendet werden.

• Aktueller Stand:

  • Neuer Container läuft mit:

    docker run -d \ --name=nextcloud \ --restart=unless-stopped \ -e PUID=99 \ -e PGID=100 \ -e TZ=Europe/Berlin \ -p 8080:80 \ -p 448:443 \ -v /mnt/user/appdata/nextcloud/:/config/ \ -v /mnt/user/nextcloud/:/data/ \ lscr.io/linuxserver/nextcloud:latest

  • Webzugriff: https://MEINE-UNRAID-IP:448

  • Die Daten der Benutzer liegen in /mnt/user/nextcloud/ mit Unterordnern D..., G.., Kl... usw. (darin files, files_trashbin, uploads usw.).

  • Konfiguration liegt in /mnt/user/appdata/nextcloud/config/.

  • Ausschnitt aus config.php:

    php

    'dbtype' => 'mysql', 'dbname' => 'nextcloud', 'dbhost' => '192.168.xxx.xx:3306', 'dbport' => '', 'dbtableprefix' => 'oc_', 'mysql.utf8mb4' => true, 'dbuser' => 'nextcloud',

  • Die Datenbank liegt also auf einem separaten MySQL/MariaDB‑Server (Host 192.168.xxx.xx, DB nextcloud, User nextcloud).

  • Logauszug des neuen Containers (verkürzt):

    text

    Linuxserver.io version: 32.0.4-ls412 Initializing nextcloud 32.0.4.1 (this can take a while) ... Upgrading nextcloud from 32.0.3.2 ... Setting permissions Setting log level to debug Turned on maintenance mode Updating database schema Exception: Database error when running migration 33000Date20251209123503 for app core Index "mounts_user_root_path_index" does not exist on table "oc_mounts". Update failed Maintenance mode is kept active Resetting log level

    → Danach zeigt die Weboberfläche „Aktualisierung erforderlich“ bzw. Wartungsmodus.
    → occ‑Befehle im Container schlagen fehl, weil im Pfad kein occ gefunden wird.

  • Ordnerstruktur im Container (docker exec -it nextcloud bash):

    text

    /config/ .migrations

  • config.php.save

  • data/

  • nginx/

  • php/

  • www/

  • /config/www/

  • index.html

  • nextcloud/

  • /config/www/nextcloud/

  • apps/

  • config/

  • themes/

  • (KEIN occ, KEIN index.php, KEIN version.php etc.)

    Es sieht also so aus, als wären nur apps und config aus der alten Installation vorhanden, aber der eigentliche Nextcloud‑Core (PHP‑Dateien) fehlt oder wurde beim Versuch, neu zu installieren/zu updaten überschrieben.

  • Was ich NICHT machen möchte:

    • Keine Experimente direkt in der MySQL‑Datenbank ohne Anleitung.

    • Keine Löschung der Daten in /mnt/user/nextcloud/ oder /mnt/user/appdata/nextcloud/config/.

    • Kein weiteres „Herumprobieren“ mit zufälligen occ- oder SQL‑Befehlen.

    Was ich gerne erreichen möchte:

    • Die bestehende Datenbank (nextcloud auf 192.168.xx.xx) weiterverwenden.

    • Die bestehenden Daten im Share /mnt/user/nextcloud/ (Benutzerordner D..., G.., K... usw.) weiterverwenden.

    • Einen sauberen linuxserver/nextcloud‑Container, der:

      • wieder einen vollständigen Nextcloud‑Core unter /config/www/nextcloud hat,

      • das Datenbank‑Schema korrekt auf den aktuellen Stand hebt (Fehler mit mounts_user_root_path_index behebt),

      • und danach normal startet (Login der alten Benutzer möglich ist).

  • Meine Frage an euch:

    1. Wie sollte ich konkret vorgehen, um den fehlenden Nextcloud‑Core nach /config/www/nextcloud zu bringen, ohne meine bestehende config und apps zu überschreiben?

       • Welche genaue Nextcloud‑Version sollte ich dafür verwenden (passend zu 32.0.3.2 → 32.0.4.x)?

       • Welcher tar/rsync‑Befehl ist hier empfohlen?

    2. Wie kann ich anschließend sicher die Datenbankmigration reparieren:

       • z.B. mit occ db:add-missing-indices, occ maintenance:repair, occ upgrade – welche Befehle in welcher Reihenfolge sind hier sinnvoll, wenn der Fehler „Index mounts_user_root_path_index does not exist on table oc_mounts“ kommt?

       • Gibt es ggf. ein bekanntes SQL‑Snippet, um diesen Index manuell auf der DB nextcloud anzulegen, falls occ erneut scheitert?

    3. Falls es sinnvoller ist:

       • Würdet ihr eher eine frische Nextcloud‑Instanz (gleiche oder höhere Version) aufsetzen, diese mit derselben DB verbinden und dann occ upgrade laufen lassen?

       • Oder würdet ihr einen „Rollback“ auf eine ältere Nextcloud‑Version empfehlen, die besser zum Datenbank‑Stand passt?

    Zusammenfassung:

    • Alte Daten und DB sind noch da.

    • Neuer linuxserver‑Container läuft, bricht aber beim DB‑Update ab.

    • Nextcloud‑Core im Container ist unvollständig (kein occ).

    • Ziel: Saubere Wiederherstellung mit vorhandener DB und Daten, ohne Datenverlust – brauche hier eine Schritt‑für‑Schritt‑Anleitung, insbesondere für das Neu-Einspielen des Cores und die richtige Reihenfolge der occ/SQL‑Befehle.

    Vielen Dank schon mal für jede Hilfe!

• "Keine Experimente" verstehe ich, aber hast du insbesondere von den DB-Dateien Kopien erstellt? Ich frage, weil bereits der Start mit einem deutlich neueren MariaDB Container oder einer deutlich neueren Nextcloud Version könnte ja dazu führen kann, dass deine DB verändert wird. Also egal was du machst, solltest du auf keinen Fall mit deinen Originaldateien machen, sondern nur mit Kopien.

• Außerdem empfehle ich sowohl MariadB als auch Nextcloud auf die Version zu setzen, die deine Dateien aktuell haben. Dazu ändert man die Zeile Repository von lscr.io/linuxserver/nextcloud in lscr.io/linuxserver/nextcloud:32.0.3. Dann ist die Wahrscheinlichkeit hoch, dass er erst mal gar kein Upgrade versucht und du kannst erst mal schauen, dass du mit der vorhandenen Version starten kannst. Später kannst du zB :latest für die neueste Version oder eben andere spezfische Versionen auswählen. Eine komplette Liste dieser tags findest du hier:
  https://hub.docker.com/r/linuxserver/nextcloud/tags

• Der Fehler app core Index "mounts_user_root_path_index" does not exist on table "oc_mounts" klingt so, als sei die Datenbank unvollständig oder passt nicht zu der erwarteten Nextcloud Version 32.0.3.2. Du hast geschrieben, dass du kurz weg von Docker warst, also VM? Welche Datenbank-Dateien hast du denn jetzt, die von Docker-Zeiten oder die aus der VM? EDIT: Laut KI soll mounts_user_root_path_index nicht neu in Nextcloud 32 (sondern soll schon seit Nextcloud 14 existieren) dazu gekommen sein. Falls das stimmt, wäre das ein Indiz für eine korrupte Datenbank. Ich schlage vor, dass du einen DB Viewer installierst und dir erst mal die Struktur der DB anschaust. In den Unraid Apps findest du dafür zB Adminer. Für den PC ginge auch HeidiSQL. Dann schaust du mal, ob alle erwarteten Tabellen da sind, Daten enthalten und ob die Spalte mounts_user_root_path_index in der Tabelle oc_mounts existiert.

• Hast du auch einen SQL Export von deiner DB? (also nicht nur die Binärdateien)

• Ich habe den Linuxserver Container installiert und nach deinen vermissten Dateien gesucht:

root@55aa6cd315ee:/# find / \( -iname "occ" -o -iname "nextcloud" -o -name "index.php" -o -name "version.php" -o -name "config.php" \) 2>/dev/null
/usr/bin/occ
/app/www/src/3rdparty/nextcloud
/app/www/src/apps/dashboard/templates/index.php
/app/www/src/apps/files/templates/index.php
/app/www/src/apps/logreader/templates/index.php
/app/www/src/index.php
/app/www/src/occ
/app/www/src/ocs-provider/index.php
/app/www/src/version.php
/app/www/public/3rdparty/nextcloud
/app/www/public/index.php
/app/www/public/occ
/app/www/public/version.php
/app/www/public/ocs-provider/index.php
/config/www/nextcloud
/config/www/nextcloud/apps/dashboard/templates/index.php
/config/www/nextcloud/apps/files/templates/index.php
/config/www/nextcloud/apps/logreader/templates/index.php
/config/www/nextcloud/config/config.php

• Demnach liegt alles was du vermisst außerhalb von /config und kann daher gar nicht fehlen, weil es zu den Dateien des Containers gehört. Das würde ich also erst mal als Problem ausschließen und mich auf die DB konzentrieren. Je nachdem was du herausgefunden hast, machen wir dann weiter.

Gibt es keinen Experten der sich das Problem mal ansehen kann?

Hallo mgutt, danke für deine Antwort.

Die cco Daten lagen wirklich ausserhalb von config.

Ich habe es soweit hinbekommen Dank chatgbt das es erstmal wieder läuft und ich über Web auf nextcloud zugreifen kann und auch auf dem unraid auf die Dateien.

Morgen mach ich noch feinarbeiten.

Im Moment zeigt er mir noch nextcloud im docker als drittanbieter an und ein Web Zugang im picktogramm ist auch nicht zu sehen bzw kann ich auch noch nicht in die Einstellung für nexcloud im docker

Mfg