Nextcloud Fehler: Synchronisation wegen ungültiger Änderungszeit nicht möglich – die Lösung

Wer diesen Fehler sieht und auch ERNST NIMMT, der bekommt oft Angstschweiß.

Was macht Nextcloud jetzt schon wieder?

Warum funktioniert die Synchronisierung nicht?

Was kann ich dagegen machen?

 

Auf all diese Fragen gibt es eher keine Antworten.

 

Das Problem – Daten werden einfach nicht gesynct

Das Problem ist gravierend.

Nextcloud verweigert hier die Synchronisierung, also das Speichern der Daten am Server.

Die Daten landen also gar nicht auf der Nextcloud-Instanz!

Wer immer davon ausgegangen ist, dass die eigenen Daten eh sicher auf dem Nextcloud-Server gespielt werden, der irrt.

Dazu gibt es natürlich auch schon einen Thread im Support Forum: https://help.nextcloud.com/t/server-meldet-ungultige-anderungszeit/130268

Warum?

In meinem Fall war das Problem, dass kein Änderungsdatum bei der Datei eingetragen war.

Ohne dass eine Datei einen Zeitstempel besitzt der anzeigt, wann die Datei das letzte mal geändert wurde, verweigert der Sync Client auf Ubuntu den Dienst!

 

Die Lösung – Jede Datei „angreifen“ und einen Änderungszeitpunkt geben

Ich will mich mit dem Problem nicht lange aufhalten.

Mir ist es auch egal, wenn die Änderungszeitpunkte nicht stimmen, ich also nicht den tatsächlichen, letzten Änderungszeitpunkt in der Datei stehen habe.

Mir ist es wichtig, dass meine Daten gesichert werden!

Daher bin ich folgenden Hardcore-Weg gegangen:

Einfach alle Dateien einmal „angreifen“, also den Befehl „touch“ über alle Dateien drüberlaufen lassen:

find . -type f -exec touch {} +

Das funktioniert wunderbar!

Es öffnet einem die Augen wenn man den Nextcloud Sync startet.

Auf einmal möchte der Nextcloud Client eine Menge Daten hochladen von denen man gedacht hat, die wären alle schon gesichert oO!

 

Der Supergau! Kaputte verschlüsselte Daten mit Nextcloud gesynct. Wie kann ich Daten retten?

Das Setup

Ich hab meine Dateien mit gocryptfs https://wiki.ubuntuusers.de/GoCryptFS/ verschlüsselt.

Diese Dateien landen dann in der Nextcloud.

Das ist für mich ziemlich sicher. Weil keine unverschlüsselten Dateien die Festplatte verlassen.

Weil weder die Ordnerstruktur noch die Dateinamen nachvollziehbar sind.

Warum? Hab ich was zu verstecken? JA! Wir arbeiten für Kunden und deren sensible Daten. Datenschutz und Privatsphäre, ey! Es soll keine Nachvollziehbarkeit geben, wenn (nicht falls) es zu einem Datenleck kommt.

Aus Datenrettungssicht das komplette Gegenteil von optimal. Wenn eine Datei kaputt geht, weiß ich nicht in welchem Verzeichnis die Datei steckt, und wie die Datei heißt.

Bad. Noch schlechter: Wenn jetzt wirklich was passiert!

Der Sync-Super-GAU: Kaputte Daten überschreiben gesunde.

Wenn Daten auf der Festplatte kaputt gehen, ist das schlimm. Passieren kann das schon mal, wenn einzelne Sektoren von Festplatten/SSDs nicht mehr wollen.

Oder weil Ubuntu unerwartet abgeschossen wird.

Aber es geht noch schlimmer!

Was ist, wenn ich diese Daten nun mit der Cloud synce und somit auch auf andere Geräte übertrage.

Die gu(r)te Datei hätte sich besser anschnallen sollen, denn jetzt ist sie verunfallt.

Geht es noch schlimmer?

Noch schlimmer ist es, wenn die Dateien verschlüsselt sind, kaputt gehen und gesynct werden.

Vor allem dann, wenn man die Dateinamen mitverschlüsselt, so wie hier mit gocryptfs:

 

 

Keine Ordnernamen!

Keine Dateinamen!

KEINE ORDNERSTRUKTUR, die ich nachvollziehen kann.

Das ist der Zeitpunkt, wo man sich vielleicht umorientieren sollte.

Irgendwas mit Holz, kein Strom. Irgendwas mit Natur.

Es hilft alles nix, Kopf in den Sand stecken ist keine Option – aber ein Wiki-Eintrag: https://en.wikipedia.org/wiki/Ostrich_effect

Was ist die Lösung? (Schön, dass du nicht frägst, ob es überhaupt eine Lösung gibt, sondern dass du davon ausgehst, dass es eine gibt. Positv denken! Ganz wichtig, in dieser Situation!)

Die Lösung

  • Inode Nummer herausfinden
  • das verschlüsselte Äquivalent finden
  • bei Nextcloud nach Datei suchen
  • Versionshistorie öffnen und
  • frühere Version herunterladen.

Easy, right?

Inode Nummer herausfinden

Easy: ls -li meine_kaputte_datei.txt

Dadurch bekomme ich die Inode-Nummer:

Also die genaue Position im Dateiverzeichnis

Das verschlüsselte Äquivalent finden

find -inum 6428899

Bringt folgendes Ergebnis:

Bei Nextcloud nach Datei suchen

Mit dem Dateinamen

Lw__wJkaqDRA1XSqWiqzoBkt3o-w71BOhRE27KlgN2rbYGyB6CLeY-x8fUbfpU7WeJlaHlW9jvlLevJ8-EWXk40-FPqOIMCHrSq0Bl9tVmc

kann ich jetzt in die Weboberfläche von Nextcloud gehen und danach suchen:

Auf den nicht fett gedruckten Text klicken und man kommt in das richtige Verzeichnis:

Und wir sehen: 0 KB! Das is böse, das tut in der Magengrube weh!

Aber weiter geht’s:

Versionshistorie öffnen

Das ist unsere Rettung!

Dank Nextcloud/Owncloud kommen wir noch an unsere frühere Version heran!

Jetzt nur noch die Datei downloaden. Es kommt die verschlüsselte Datei herbei, ergo muss auch die 0KB Datei-Version im Ordner, wo die verschlüsselten Dateien liegen, überschrieben werden.

 

Tut euch selber einen gefallen, und sichert alle Daten auch nochmal lokal. Regelmäßig. Wirklich. Regelmäßig! Kauft euch eine gute und günstige SSD wie eine Crucial:

 

Und dann: SICHERN SICHERN SICHERN!

Verschlüsselte Daten und Dateikonflikt beim Syncen mit dem Nextcloud Desktop Client

Nextcloud Sync?

Für Nextcloud gibt es einen Ubuntu-Sync-Client, der im Appstore (Ubuntu Software) und auf der Seite von Nextcloud herunterladbar ist:

Verschlüsselte Dateien

  • Ich verschlüssele die Dateien mit gocryptfs und sirikali.
  • Daher bleibt die Verzeichnisstruktur und die Datei selbst in der Hierarchie erhalten.

    Problem beim Syncen

  • Da die Dateinamen aber auch verschlüsselt sind, weiß ich jetzt nicht genau, welche Datei vom Problem betroffen ist.

Probleme beim Syncen mit Nextcloud

Es kann vorkommen, dass folgender Fehler auftritt:

Der berüchtigte und gefürchtete "Es existieren ungelöste Konflikte. Für Details klicken." Fehler.

Wie behebt man den?

Problembehebung

Fehlerübersicht

  • Zuerst mal auf diesen gelben Balken klicken, dann kommt die Fehlerübersicht:
  • Dann auf das Ordnersymbol neben dem Fehler klicken – klickt man auf den Text selbst, passiert oft nix.
  • Ok! Ich bin jetzt bei der verschlüsselten Datei – aber wie finde ich die unverschlüsselte?

Datei finden mit ls -li

  • Den Ordner jetzt im Terminal öffnen und mit ls -liplus dem Dateinamen nach der Inode-Nummer der Datei suchen.

  • Mit dieser Inode Nummer gehe ich in das Verzeichnis, wo die unverschlüsselten Dateien liegen und führe den Befehl

  • find -inum 13414018 aus. Wobei 13414018 für die mit ls -li gefundene Nummer steht.

  • Und somit habe ich die unverschlüsselte Datei und kann nun kontrollieren, wo es Probleme gibt!