Anbieter: all-inkl
Betriebssystem: Linux 5.15.0-107-generic x86_64
php 8.3.7
Art: mysql
Version: 10.6.16
Wie seit Jahren wollte ich an 2 Clouds auf grundsÀtzlich verschiedenen Servern bei all-inkl (privat und dienstlich) das Update von
29.02 â 29.03
durchfĂŒhren per automatischen Updater im Webinterface.
Und bei beiden passierte exakt das Gleiche, das Update war unvollstÀndig, es fehlten komplette Ordner.
Bei Aufruf blieb das Webinterface leer, komplett leer. Keine Fehlermeldung white screen eben.
Das Problem fĂŒr mich war jetzt, welchen Status habe ich aktuell?
Hat der Updater die Datenbank schon angepasst?
Also legte ich erstmal eine neu leere 29.02 NC an um festzustellen, was an Ordnern fehlte.
Vorhanden waren:
3rdparty
apps
config
data
ocs
resources
themes
updater
und alle Dateien im root.
es fehlten:
core
dist
lib
ocs-provider
Ich habe das originale Verzeichnis erstmal âunangetastetâ gelassen und die vorhandenen oberen Restdateien in die neue 29.02 Installation kopiert, sowie die Config-Dateien.
Mit Daten von 25 GB aus Data dauert das schon ziemlich lange.
Bei der DB dann die originale DB belassen in der Zuweisung, da ich angenommen hatte, dass diese nicht aktualisiert wurde, was vermutlich stimmt.
"Dann die originale Domain in dieses Verzeichnis umgehangen und siehe da, zumindest hatt ich wieder Zugriff mit einem Schwung Fehlermeldungen in der nc.
** An exception occured while running the setup check: Error: Call to undefined method OC\Repair\RepairMimeTypes::migrationsAvailable() in /www/htdocs/wxxxxxx/domain.de/apps/settings/lib/SetupChecks/MimeTypeMigrationAvailable.php:36 Stack trace: #0 /www/htdocs/wxxxxxx/domain.de/lib/private/SetupCheck/SetupCheckManager.php(51): OCA\Settings\SetupChecks\MimeTypeMigrationAvailable->run() #1 /www/htdocs/wxxxxxx/domain.de/apps/settings/lib/Controller/CheckSetupController.php(179): OC\SetupCheck\SetupCheckManager->runAll() #2 /www/htdocs/wxxxxxx/domain.de/lib/private/AppFramework/Http/Dispatcher.php(232): OCA\Settings\Controller\CheckSetupController->check() #3 /www/htdocs/wxxxxxx/domain.de/lib/private/AppFramework/Http/Dispatcher.php(138): OC\AppFramework\Http\Dispatcher->executeController(Object(OCA\Settings\Controller\CheckSetupController), 'check') #4 /www/htdocs/wxxxxxx/domain.de/lib/private/AppFramework/App.php(184): OC\AppFramework\Http\Dispatcher->dispatch(Object(OCA\Settings\Controller\CheckSetupController), 'check') #5 /www/htdocs/wxxxxxx/domain.de/lib/private/Route/Router.php(338): OC\AppFramework\App::main('OCA\\Settings\\Co...', 'check', Object(OC\AppFramework\DependencyInjection\DIContainer), Array) #6 /www/htdocs/wxxxxxx/domain.de/lib/base.php(1050): OC\Route\Router->match('/settings/ajax/...') #7 /www/htdocs/wxxxxxx/domain.de/index.php(49): OC::handleRequest() #8 {main}"*
(Domainname und W-Nummer anonymisiert)
Diese Meldung erschien nur im ersten Aufruf, wurde wohl aber Serverseitig automatisch korriegiert.
* Einige Dateien haben die IntegritĂ€tsprĂŒfung nicht bestanden. [List of invalid filesâŠ](https://domain.de/index.php/settings/integrity/failed) [RescanâŠ](https://domain.de/index.php/settings/integrity/rescan) Weitere Informationen findest du in der [Dokumentation â](https://docs.nextcloud.com/server/29/go.php?to=admin-code-integrity).
Und dann die ĂŒblichen Serverfehler, welche man ĂŒber die .htaccess beseitigen kann Speichergrenze 512 MB, 41 Fehler im Protokoll seit dem Update und Hinweise zu fehlenden Indizes usw.
NC ist erreichbar, das ist die Hauptsache.
Kann jemand hier ewtas mit dem groĂem Fehlerblock anfangen?
Ich habe ja bei dem Provider kein direkten Serverzugang per SSH, also Tipps, wie man direkt auf den Server zugreifen kann, helfen gar nicht.