Backup: Fehler23 - und das Problem mit Dateinamen über 130 char bei eCryptfs+

Question

Hallo,

ich reihe mich nach einer Systemumstellung mittlerweile auch in die Reihe der vom "Fehler23" geplagten Synology-Nutzer ein.

Das Backup wird vollständig aufs Netzlaufwerk kopiert und ist konsistent. Trotzdem melden die ServerTools: Kopieren des Backups auf /Volumes/Tomedo-Backup nicht möglich! Problem: Fehler 23: Zugriff verweigert. Eventuell stimmen die Zugriffsrechte auf dem Zieldatenträger nicht?

-> Die Erklärung findet sich unten

Comments

Der Fehler tritt sowohl bei Shares mit AFP als auch bei Shares mit SMB auf.

Was die Server-Tools über haupt nicht tolerieren ist ein NFS-Share?? Der Rest vom Rechner kann aber prima auf den zugreifen...

---

Nach Analyse des Logs stellt sich heraus, dass die Dateinamen der Anhänge zu lang sind...

2018-08-02 08:06:48.654 ServerToolsHelper.m:527[lvl=1] rsync: recv_generator: failed to stat "/Volumes/Tomedo-Backup/files/2017/07/41916057700532225_2835__L0_2835__Sie_haben_ein_Fax_von_XXX_an_die_Rufnummer_XXX_erhalten.eml": File name too long (63)

Man müsste also Tomedo beibringen maximal 255 Zeichen zu speichern...

Answer 1

Das Problem scheint komplexer zu sein als zunächst angenommen.

Tomedo sollte ! unbedingt ! die maximal zulässige Länge der Dateinamen auf 130 char beschränken.

Die Erklärung findet sich hier: https://forum.synology.com/enu/viewtopic.php?t=59145

und hier nochmal genauer erklärt: https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs#answer-32834

Da sicherlich nicht nur Synology eCryptfs benutzt und tomedo die Backups nicht verschlüsselt

Comments

Ich denke, dass es, sieht man sich die Ordnerstruktur des "files"-Ordners an, nicht möglich sein wird, die Länge des Pfad+Dateinamens auf 130 Zeichen zu begrenzen. Aus meiner Sicht ist die sinnvollste Möglichkeit, das Backup durch die Server-Tools in eine gezippte, passwortgesicherte Datei zu packen, die dann natürlich entsprechend kurz benannt werden und in einen verschlüsselten Ordner gesichert werden kann. Der Button ist schon lange in den Server-Tools da, die Funktion erwarte ich schon mindestens ebenso lang.

Synology erlaubt auch in einem verschlüsselten Ordner keine Pfad+Dateinamen > ca. 140 Zeichen. Daher muss ein Backup in einen solchen Ordner fehlschlagen.

Trotzdem - momentan läuft auf meiner Synology (ich habe noch eine DS216play in der Praxis stehen) das Backup in einen - derzeit leider notgedrungen unverschlüsselten - Ordner fehlerlos durch. Von da an geht es über Hyperbackup verschlüsselt offsite. Gerne würde ich das anders lösen, hier fehlt es aber eindeutig an programmiertechnischer Hilfe von Zollsoft. Mit dem Problem der verschlüsselten Backups wird man leider alleine gelassen und meine Fragen hierzu in anderen Tröds an Zollsoft sind leider ungehört verhallt...

Spätestens seit der DSGVO ist das Thema hochbrisant und an einen Einbruch in der Praxis bei der das NAS geklaut wird, darf man gar nicht denken...

---

Ich denke nicht, dass es auf Zollsoft-Seite ein Problem darstellen sollte. Die Dateien werden ja ohnehin mit irgendwelchen Zahlenkombinationen versehen - muss denn dann noch der Text hinten dran?

Also statt

/Volumes/Tomedo-Backup/files/2017/07/41916057700532225_2835__L0_2835__Sie_haben_ein_Fax_von_XXX_an_die_Rufnummer_XXX_erhalten.eml

Einfach nur 

/Volumes/Tomedo-Backup/files/2017/07/41916057700532225_2835__L0_2835

Damit klappt dann auch das kopieren auf einen verschlüsselten Synology-Ordner....

 

dass das Backup eigentlich ohnehin komplett verschlüsselt gespeichert werden sollte (und dies aus Performancegründen innerhalb eines Containers) versteht sich von selbst... :P

---

Die Zuordnung ist ja nicht immer so eindeutig wie bei diesem Dateinamen. Zudem müßten dann auch in den Datenbanken aller Benutzer bereits bestehende Dateinamen entsprechend gekürzt/umbenannt werden. Ob das funktionieren würde ohne hinterher mit Dateileichen rechnen zu müssen, kann wohl nur Zollsoft beantworten.

Answer 2

Wie Sie schon richtig analysiert haben, NFS kann nur 255 Zeichen lange Dateinnamen. OSX hat diesbezüglich aber keine Beschränkung. Ich sehe nicht das wir einfach so das begrenzen könnten. Das wäre sehr viel Arbeit und würde zu viele mögliche Fehler mit sich bringen. Evtl sollten Sie abstand von NFS nehmen.

Comments

Lieber Herr Thierfelder, trotzdem möchte ich an dieser Stelle nochmals dringend anregen, die Verschlüsselung des Backups durch die ServerTools zu implementieren. Als Laie würde ich behaupten, das das so schwer ja nicht sein kann. Und die Problematik wird sich wahrscheinlich für viele Ihrer Kunden stellen, oder wie lösen andere Praxen das Problem mit verschlüsselten Backups?

---

Um ehrlich zu sein, ja, das ist ein Problem. Wenn die Servertools alles verschlüsseln würden gibt es 2 Optionen.

1. Alles in einer Datei: Sie würden bei jedem Backup Tage warten. Der Filesordner ist ja meist recht gross. Und der muss in einem Schwung verschlüsselt werden.

2. Jede Datei einzeln: Nicht optimale Sicherheit, aber ok. (Oder man Verschlüsselt noch den Dateinamen... auch nicht viel besser.) Größtes Problem ist aber: Wenn etwas verschlüsselt ist, so wissen wir nicht, ob die verschlüsselte Datei den gleichen Inhalt hat wie aktuelle Datei -> Man muss alles erneut verschlüsseln... oder entschlüsseln vergleichen verschlüsseln. Nichts gekonnt.

=> Auf Fileebene ist das nicht machbar. Wieso nicht auf das Dateisystem setzen?

https://www.maceinsteiger.de/how-to/festplatte-verschlusseln/

Oder halt eine Hardwareverschlüsselung.

---

DIe Hardwareverschlüsselung sorgt doch meines Wissens nur dafür, das der Verschlüsselungsvorgang "on the fly" (bei Synology z.B. in einen verschlüsselten Ordner) schneller läuft, da das NAS hierfür einen zusätzliche Chip bereitstellt, der die Berechnungen übernimmt (zB. die DS218+). Die ganze Platte an sich ist aber nicht automatisch verschlüsselt und es bleibt das Problem der Zeichenbegrenzung der Dateinamen.

Eine externe Festplatte mit macOS zu verschlüsseln funktioniert lokal, kann aber nicht so einfach nach offsite gesichert werden, da wir hier wieder das macOS-Dateisystem haben, das z.B. mit dem Filesystem der Synology, welche die Offsite-Sicherung übernimmt, nicht kompatibel ist (ähnlich dem Problem einen "Fotos"-Container auf ein NTFS-Laufwerk sichern zu wollen. Das geht schlicht nicht. Eine Offsite-Sicherung ist aus meiner Sicht aber absolutes Muss. Und täglich mit Festplatten im Rucksack rumlaufen zu müssen, das sehe ich nicht ein, das muss anders - und zwar automatisch - gehen.

Sehen Sie sich mal im App-Store die Software "Crypt Sync Files" an. So stelle ich mir das Ganze vor. Schön wäre natürlich eine Zollsoft-Lösung in einem Guss. Beispielsweise existiert ein gemounteter Netzwerkordner, in den der gesamte Inhalt des files-Ordners "on-the-fly" verschlüsselt gesichert wird, Änderungen werden sofort one-way gesynct. Zusätzlich erfolgt ein tägliches Backup der restlichen Dateien wie jetzt auch in einzelne Ordner mit einer Konsistenzprüfung des "files-Ordners" im Rahmen des allabendlichen Backups. Dieses verschlüsselte Gesamtpaket kann dann guten Gewissens nach Offsite gesichert werden.

---

Wieso nicht auf Filebene Herr Thierfelder?

Seit 10 Jahren scheinen weder KODI noch Plex Probleme damit zu haben Filme abzuspielen die in verschlüsselter Form innerhalb von 50 ZIP-Dateien liegen. Man muss lediglich das Passwort hinterlegen. Der Film kann ohne Verzögerung aus den gepackten Dateien angeschaut werden.

Ich würde das komplette Backup einfach klassisch in ZIP Dateien zu je 100MB Packen und mit einem Passwort versehen. Damit hätte es das rsync auch viel leichter und das Backup würde beim Kopieren deutlich an Geschwindigkeit zunehmen.

Das Backup zu erstellen würde damit dann vielleicht 5 Minuten länger dauern, aber das Kopieren wäre viel schneller .... und das dauert deutlich länger als das Erstellen...