Jetzt sind auf der Nextcloud einige Dateien von unterschiedlichsten Nutzern verschlüsselt. Der eine Nutzer kann Dateien anzeigen, der andere nicht, bei einigen Dateien kann kein Nutzer mehr die Datei entschlüsseln. Der Fehler tritt seit einigen Wochen bei immer mehr Dateien auf.
Wir haben zum Glück mehrere Backups aller Dateien unverschlüssselt.
Mein Plan ist nun folgender, dass ich alle Dateien auf der cloud Seite lösche, ein Backup mit rsync einspiele, und anschliesend einen scan:all ausführe. Im Vorfeld möchte ich für alle Benutzer die Option zur Verschlüsselung deaktivieren. Wie kann ich das durchführen? Kann ich für alle Benutzer die Ordner /path/to/data/nutzer/files_encryption/ einfach löschen bevor ich das Backup wieder einspiele? Kann der Plan so funktionieren?
Viele Grüße
Sven
Erstmal ist deine Nextcloud veraltet. Ziehe in Betracht in nächster Zeit ein Upgrade auf Debian 12 Bookworm mit Nextcloud 26, 27 oder 28 durchzuführen. Überlege dir wie du das durchführen willst. Du kannst keine Version überspringen.
Überlege dir wie sinnvoll oder sinnlos eine serverseitige Verschlüsselung ist. Sofern du keinen External Storage wie z. B. S3 bei einen anderen Anbieter nutzt, ist die serverseitige Verschlüsselung ziemlich sinnlos. Beschäftige dich damit und überlege, ob du sie zukünftig benötigst.
Du führst an, dass du bereit bist die Daten zu löschen, neu einzuspielen und dann neu zu scannen. Dir ist klar, dass du alle Shares verlieren wirst? Wenn das ok ist, dann besorge dir gleich eine neue Nextcloud 28 (temporär anderer Name), installiere alles neu, Backup zurückspielen, file:scan und dann evtl. auf den alten Namen zurückwechseln.
Tipp: Du nutzt eine ziemlich alte Nextcloud-Version. Scheinbar machen dir Updates kein Spaß. Vielleicht wäre es sinnvoller die Managed Nextcloud von Hetzner Storage Share zu verwenden. Ich denke Hetzner kann sich besser um die Nextcloud kümmern als du. Du kannst ja mit der günstigen NX11 (5 Euro, 1 TB) einsteigen und die Leute erst mal dahin migrieren während dein vServer noch existiert. Über den Nextcloud-Client (z. B. Windows) kann der Benutzer seine Daten auch selbst migrieren sofern er nicht die oben aufgeführten Zugriffsprobleme hat. Den Benutzern mit Problemen gibst du deren Backup und auch die können sich selbst um ihre Daten kümmern. Das Backupkonzept der Managed Nextcloud von “Storage Share” kenne ich nicht. Evtl. solltest du dafür etwas zusätzliches Geld in die Hand nehmen.
Eine serverseitige Verschlüsselung ist nicht sinnvoll, weshalb ich sie auch deaktivieren will. Mir ist nicht mal bewusst, wie es dazu kam, bei einzelnen Dateien und Nutzern. Für das Problem mit der veralteten Version mache ich wohl, nachdem ich selbst gesucht habe, eine neues Thema auf, weil mir nämlich meine Installation sagt, sie sei up to date, und das auch noch, nachdem ich auf Updatekanal Beta geschaltet habe. Ich hab mich schon gefragt, wann bei stable mal wieder was vorwärts geht.
Es sind nur 4 Benutzer, da wäre dann eine Neuinstallation wirklich eventuell das Beste. Freigabelinks können neu erstellt und verteilt werden.
Sorry, aber wenn du dein OS und PHP nicht managen/upgraden kannst oder willst, ist eine “Managed Nextcloud” wie @devnull sie vorgeschlagen hat wahrscheinlich die bessere Lösung.
Oder willst du jedesmal alles neu installieren, wenn Nextcloud eine neuere PHP-Version benötigt, als deine momentane Debian-Version gerade zur Verfügung stellt
@bb77 Also ich verwende immer die in der Distribution aktuelle Version von PHP. In diesem Fall von @sven222 hätte ich aber längst von Debian 11 Bullseye auf Debian 12 Bookworm das Debian-Release hochgezogen, wodurch es dann die neuste PHP-Version gegeben hätte. Leider ist das Upgrade etwas schwierig zwischen Debian Bullseye/Bookworm, PHP 7.4/8.2 und Nextcloud. Für die meisten ist wohl wirklich eine externe PHP-Quelle einfacher.
Ich meine mit etwas “Trickserei” ist das auch ohne externes Repo möglich, jemand hat mal im Forum gepostet wie er oder sie es gemacht hat. Ich bin mir nicht sicher, ob da ein manuelles Update von Nextcloud involviert war, oder ob man Nextcloud irgendwie trotz “falscher” PHP-Version zu einem Update zwingen kann. Es sollte aber auf jeden Fall möglich sein.
Aber ja, mit dem externen Repo ist man deutlich flexibler.
Ich glaub das war ich bei meiner Umstellung von Debian Bullseye auf Debian Bookworm, PHP 7.4 auf PHP 8.2 und irgendeiner Nextcloud-Version. Wenn ich mich recht erinnere war updater.phar lauffähig unter der neueren PHP-Version 8.2. Daher erst das Betriebssystem upgraden und dann Nextcloud und nicht umgekehrt. Oder war es umgekehrt. Steht noch irgendwo beschrieben.
