Problem beim Sichern verschlüsselter Ordner auf dem Hidrive

[matmike]

So, seit ein paar Tagen bekomme ich leider wieder Fehlermeldungen vom HiDrive-Modul:

[255] Connection to the destination server is timeout. Please check the following and try again:The destination server is connected to a stable network.Backup client and server is busy.

Die Ordner-Länge hat sich hier einmalig erhöht, die betreffenden Ordner sind aber wieder rausgenommen worden. Es ist also im Prinzip der STand von davor, trotzdem geht es nicht mehr.
Habt ihr noch Ideen, was ich machen kann?

Danke,
Matthias

 

[franky1080]

Hallo Matthias,

ich habe das gleiche Problem seit Kurzem. Bei mir hat sich die Ordnertiefe ebenfalls nicht verändert. Zeitlich gesehen tritt das Problem seit dem Upgrade auf DSM 5.1 auf. Kann es evtl. an der neuen DSM Version liegen?

 

[matmike]

Ich hatte das HiDrive-Modul nur kurz in Verbindung mit DSM5.1(beta+normal) in Verwendung und habe wegen der Kosten und Flexibilität dann auf Amazon S3 gewechselt.
Ich habe es nicht wirklich in den Griff gekriegt und habe den verschlüsselten Teil einfach einmal gelöscht und neu angelegt - dann direkt ohne die langen Ordner. Danach hat es wieder problemlos funktioniert.
Beim Amazon S3 gibt es übrigens auch eine Beschränkung, da sind es anscheinend 1024 Zeichen für den gesamten Pfad und nicht die Tiefe an sich.Bei Interesse kann ich mal die Excels die ich verwendet habe zur Feststellung was los ist hier zur Verfügung stellen.

Viele Grüße,
Matthias

 

[franky1080]

ok, hab die Ursache zwischenzeitlich gefunden. Durch den Mediaserver werden immer die berühmten @eadir Verzeichnis kreiert, die man aus Windows heraus aber nicht sehen kann. In einem Ordner hat dieses Verzeichnis am Ende für eine zu lange Pfadlänge > 1024 Zeichen gesorgt. Nachdem ich das eliminiert hatte, läuft es wieder.

PS: Strato hat das gleiche Limit wie Amazon (1014 Zeichen Pfadlänge). Das ist keine Limitierung der Provider, sondern ein Limit im rsync Protokoll. Die Anzahl maximaler Ordner leitet sich ungefähr daraus ab, dass verschlüsselte Dateien und Ordner nach meinen Recherchen aus 84 bis 104 Zeichen bestehen. Daraus folgt, dass ein Pfad max. aus 8 Ordner + Dateiname bestehen darf.

Wenn man ganz sicher gehen will, kann man wie folgt vorgehen (danke an meinen Bruder!): auf der Diskstation via SSH in den betroffen verschlüsselten Ordner wechseln, also z.B. cd /volume1/@my_folder@
Dann folgenden Befehl absetzen: find . > /volume1/my_folder/files_encrypted.csv

Das entsprechende csv File aus Windows öffnen und in Spalte B die =Länge Funktion nutzen, um die genaue Länge zu erkennen. Nach Spalte B sortieren und dann sollte man erkennen, ob es Problemfälle gibt (Achtung: nicht 1024 ist das Limit, sondern ca. 100 Zeichen weniger! Von den 1024 muss man noch den Ordner Namen und das Verzeichnis, dass die Synology auf dem Hidrive anlegt, abziehen).

Wenn man Problemfälle in den verschlüsselten Pfaden in Excel entdeckt, kann man sie mit einem etwas aufwendigen Verfahren auch wieder entschlüsseln:

• Erstellen eines Mount Ordners, z.B. mkdir /root/test
• Mounten eines der betroffenen Ordner (wichtig: den Dateinamen hinten abschneiden, indem man sich bis zum letzten / vorarbeitet): mount.ecryptfs <verschlüsselter Dateipfad> /root/test
• Bei den Abfragen das Passwort für den verschlüsselten Ordner eingeben, 1 für AES, 2 für 32 key bytes, n für enable plaintext passthrough und y für enable filename encryption
• Danach nach test wechseln: cd /root/test
• Jetzt kann man mit ls zumindest erkennen, welche Dateien in dem betroffen Ordner liegen
• Am Ende unbedingt wieder ein umount /root/test durchführen
• Sollte man nicht erkennen, welcher Ordner der Problemfall ist, ggf. das gleiche noch mal wiederholen, aber einen Ordner eine Ebene höher mounten.