Das Betreiben einer Nextcloud-Instanz ist bei Hostpoint eigentlich nur geduldet und der Betrieb auf einem Shared Webhosting ist von Nextcloud auch nicht supported. Für den einfachen Datenaustausch betreibe ich aber trotzdem eine Instanz auf meinem Shared Webhosting und muss diese entsprechend auch immer mal wieder updaten. Dabei treten immer wieder dieselben Probleme auf, die ich hier mit den Workarounds dokumentieren will. Die Beschreibung ist auf dem Stand von Version 25, die Probleme traten aber identisch bei den Vorgängerversionen auf und ich vermute, dass sie auch bei den nachfolgenden Releases auftreten werden.

Ich verwende in dieser Beschreibung, da meine Nextcloud-Oberfläche auf Deutsch eingestellt ist, die deutschen Bezeichnungen.

0. Backup erstellen

Eigentlich sollte es jedem klar sein, dass bei einem Update immer etwas schief gehen kann. Aber nochmals zur Sicherheit: vor jedem Update Files und Datenbank sichern!

Um umfangreiche Verzeichnisse (wie z.B. eine Nextcloud-Installation) als einzelne Datei zu Sichern habe ich ein kleines php-Tool geschrieben, das auf Knopfdruck ein Backup startet und dann das .zip-File als Download zur Verfügung stellt.

Es empfiehlt sich zusätzlich die Datei core/shipped.json einzeln herunterzuladen, da wir diese im folgenden Ablauf noch ein paar Mal benötigen werden.

1. Update starten

Als Administrator das WebUI von Nextcloud starten. Falls in den Benachrichtigungen (Glocken-Symbol) auf das Update hingewiesen wird öffnet ein Klick auf den Hinweis die Verwaltungs-Seite, von welcher aus das Update gestartet werden kann. Ansonsten kann über das Benutzer-Menü oben rechts auf Administrationseinstellungen geklickt werden und es erscheint dieselbe Seite.

Unter „Version“ wird die aktuell verwendete Version angezeigt. Wenn eine neuere Version verfügbar ist wird diese unter „Aktualisieren“ aufgeführt. Dort befindet sich auch der Knopf „Updater öffnen“, mit dem die Update-Seite geöffnet wird.

Die Update-Seite ist auf Englisch, dementsprechend kommen hier die englischen Bezeichnungen zum Zug. Es wird nochmals die Ausgangs- und die Zielversion angezeigt.

Mit „Start update“ wird das Update ausgeführt.

Es werden die verschiedenen Schritte aufgeführt. Der aktuell laufende ist mir einem drehenden Kreis markiert während die erfolgreich durchgeführten Schritte mit einem grünen Haken markiert sind.

[Update, ab Version 29.0.0]
Schon während dieser Schritte kann ein Fehler auftreten, der in der Datei data/updater.log mit folgendem Fehler auftaucht:

Exception: Exception

Message: Not authenticated

Code:0

Dies kann z.B. schon auftreten wenn man zuerst das Changelog liest, das vom Updater aus erreichbar ist.
Um diesen Fehler zu beheben reicht es mit dem Browser eine Seite zurück zu gehen, den Updater erneut aufrufen und mit „Retry update“ das Update weiter ausführen.
[/Update]

2. Delete old files

Nach einiger Zeit schlägt der Schritt „Delete old files“ fehl und ist mit einem roten „X“ und hellroter Hintergrundfarbe markiert. Leider liefert die Update-Seite keine Informationen, was genau schief gelaufen ist. Genauere Informationen findet man in der Datei data/updater.log. Dabei sind 2 Fälle zu unterscheiden, wobei es irgendwann von Fall 1 zu Fall 2 wechselt:

1. Message: Could not rmdir:
   Es ist ein Fehler beim Löschen des nach rmdir angegebenen Verzeichnisses aufgetreten.
   Man könnte nun das Verzeichnis von Hand löschen, dies ist aber gar nicht nötig. Auf der Update-Seite ist anstelle des Buttons „Start update“ nun der Button „Retry update“ vorhanden. Dieser führt das Update an derselben Stelle weiter und versucht entsprechend nochmals das Verzeichnis zu löschen, was dann meistens auch klappt.
   Man muss nicht nach jedem Fehler im Log nachschauen was passiert ist, man kann auch einfach mehrmals auf „Gut Glück“ auf „Retry update“ klicken.
2. Message: core/shipped.json is not available
   Spätestens wenn der Klick auf „Retry update“ augenblicklich wieder einen Fehler meldet sollte wieder das Log konsultiert werden. Wenn die obenstehende Meldung erscheint benötigen wir das einzeln gesicherte File. Dieses wird vermutlich beim Löschen der alten Dateien ebenfalls gelöscht, wird aber für den Retry-Mechanismus wieder benötigt.
   Entsprechend kopieren wir die Datei wieder an ihre ursprüngliche Stelle und starten dann wieder mit „Retry update“. Solange nun beim Schritt „Delete old Files“ ein Fehler auftritt müssen wir immer zuerst wieder die Datei core/shipped.json hochladen und dann wieder auf „Retry update“ klicken.
   Irgendwann wird auch der Ordner core gelöscht, dann muss entsprechend auch der Ordner wieder erstellt oder kopiert werden.

3. Move new files in place

Wenn wir beim Schritt „Move new files in place“ angekommen sind gibt es wieder Fehler der Art „Message: Could not rmdir“ (diesmal aber ohne : nach rmdir). Nun kann wiederum direkt auf „Retry update“ geklickt werden bis auch diese Fehlergruppe durchgearbeitet ist und wir beim Schritt „Continue with web based updater“ landen. Dort kann nun ber Button „Disable maintaince mode and …“ angeklickt werden und man landet bei der Aktualisierung der Apps.

4. Aktualisierung der Apps

Es werden alle Apps aufgeführt, die aktualisiert werden. Zuunterst gibt es den Knopf „Aktualisierung starten“ welche den Prozess auslöst.

Dies kann ebenfalls fehlschlagen, was zur Folge hat dass der Maintenance-Mode aktiv bleibt. Dadurch kann aber der fehlgeschlagene Schritt nicht nochmals gestartet werden.

In der Datei config/config.php muss ‚maintenance‘ auf false gesetzt werden um den Maintenace-Mode auszuschalten und den Aktualisierungsprozess weiterzuführen.

5. Abschluss

Zum Schluss sollte wieder das Nextcloud-Dashboard angezeigt werden. Der Maintenance-Mode wird dabei automatisch wieder ausgeschaltet. Auf der Verwaltungs-Seite (Benutzer-Menü oben rechts, Administrationseinstellungen) sollte nun unter „Aktualisieren“ vermerkt sein dass die Version aktuell ist. Falls dies nicht der Fall ist war man vermutlich auf auf einer älteren Major-Version und man darf das ganze Spiel (inkl. Backup!) nochmals durchführen.