Der Teufel steckt im Detail oder wie Dateien und Ordner scheinbar vom NAS verschwanden

1 Mai

Der Daten-Umzug steht an! Mein 10 Jahre(!) altes Synology NAS aus der Familie DS 1010+ pfeift, klappert und ächzt. Der Speicherplatz ist nahezu ausgeschöpft, die 24/7-Server-Platten arbeiten nach den vielen Jahren aber immer noch fehlerlos. Und fünf Jahre Herstellergarantie auf die Platten gibt es heute auch nicht mehr. Jedenfalls ein Wunder, dass die kompakte schwarze Kiste so lange stoisch durchgehalten hat. Auch ein Komplettwechsel aller drei Lüfter, die aus allen Winkeln Asiens aus Lagerbeständen beschafft wurden, konnten keine Abhilfe mehr schaffen. Schließlich wurde noch der CPU-Kühler mit neuer Wärmeleitpaste verjüngt. Aber der Geräuschpegel blieb erschreckend hoch, was ich all meiner Bemühungen zum Trotz als Zeichen des baldigen Ablebens des NAS deutete. Am Ende half alles nichts: Die alte DS 1010+ wurde durch eine neue DS920+ von Synology ersetzt. „Bye, bye, brave old fellow.“ Das neue Modell hat einen Festplatteneinschub weniger und wurde bestückt mit brutto 30 TB auf nur drei Platten statt 10 TB auf fünf. Es hat sich vor allem in Sachen Plattenplatz pro Euro eine Menge getan. 10 Jahre sind in der EDV halt eine Ewigkeit…

Der Umzug steht an. Gut, dass die wichtigsten Daten von mir stets auf externe HDDs gesichert wurden, die als HFS+ unter OS X formatiert und über den sehr empfehlenswerten Carbon Copy Cloner mit Daten befüllt wurden. HFS+ tut schon seit 1998 – also einer halben Ewigkeit – Dienst in der Apple-Welt. Der Hersteller aus Cupertino selbst bezeichnet es unter OS X als „Mac OS Extended“.

Ich wähnte mich auf der sicheren Seite: Regelmäßige Backups in einem Format, dass ich am Mac jederzeit lesen konnte. Linux als Grundlage des Betriebssystems, des sog. DiskStation Managers (DSM) von Synology, ist außerdem nicht so weit entfernt von Darwin, der Grundlage von Mac OS, die wiederum eng verwandt ist mit Unix. Jedenfalls nicht so weit entfernt wie von der Windows-Welt mit FAT32 oder NTFS, den proprietären Dateisystemen von Microsoft.

Nach dem Kopieren der Backups – vor allem meiner Musiksammlung, Fotos und Filme – auf das frische NAS stellten sich einige Merkwürdigkeiten ein. Zuerst fiel es mir unter Roon bei den Playlists auf. Die waren löchrig, unvollständig und irgendwie kürzer als noch vor dem Umzug. Bestimmte Alben konnte ich nicht finden, obwohl ich sie definitiv besaß. Auch auf der Platte waren sie nicht mehr auffindbar! Die fehlenden Tracks hatten aber eine Gemeinsamkeit: sie beinhalten diakritische Zeichen wie é, ê, è oder – noch schmerzlicher – die deutschen Umlaute…

Pfade oder Dateinamen, die solche Zeichen beinhalten, wurden nämlich nun für die Apple-Welt unsichtbar und auf meinem MacBook Pro folglich nicht mehr angezeigt. Nur, damit wir uns richtig verstehen: nicht Hieroglyphen statt der Umlaute wurden dargestellt, sondern gar nichts mehr! Anfangs irritierend, wurden diese aber auf dem NAS selbst via File Station völlig korrekt dargestellt.

Was war passiert? Linux und andere Unix-ähnliche Betriebssysteme verwenden die so genannte Normalisierungsform C (NFC) für ihre UTF-8-Kodierung. Darwin, die Basis des Macintosh-Betriebssystems, erzwingt die Normalisierungsform D (NFD), bei der einige Zeichen anders kodiert werden. Voilà! Unter OS X ist es nicht möglich, NFC UTF-8 Dateinamen zu erzeugen. Mein Glückwunsch nach Cupertino! Warum einfach, wenn es komplizierter geht?

Wie so oft, hat die Internetrecherche nach einer Lösung etliche Stunden gedauert, das Korrigieren der Dateinamen war letztlich eine Sache von Minuten! Zu verdanken habe ich das konkret Bjoern Jacke, der ein Perl-Skript geschrieben hat, mit dem es möglich ist, Dateinamen von einer Kodierung in eine andere zu überführen („tiefe Verbeugung“ meinerseits).

Auf Knopfdruck geht das jedoch nicht. Aber mit ein paar Grundkenntnissen ist es gut machbar und hilft vielleicht auch anderen Audiophilen, die sich möglicherweise fragen, wo manche Dateien und Ordner plötzlich abgeblieben sind.

Alle Ausführungen beziehen sich auf Synology NAS und Mac OS X. Achtung: Eine Haftung für mögliche, aus der unsachgemäßen Anwendung der Befehle entstehende, Schäden wird nicht übernommen!

1. Installieren Sie das Perl-Paket über das Paket-Zentrum des NAS

Das ist die Grundlage für das Skript, das später zum Einsatz kommt.

2. Aktivieren Sie SSH, falls nicht bereits aktiviert, in der Systemsteuerung auf dem NAS

Damit ist es möglich, via Terminal direkt auf das NAS zuzugreifen.

3. Melden Sie sich mit einem Admin-Benutzer per SSH auf dem NAS an

Dazu unter Dienstprogramme das Terminal-Programm auf dem Mac starten und sich am NAS anmelden wie folgt (22 ist die Portnummer. Diese muss mit der in der Systemsteuerung im NAS eingestellten identisch sein):

ssh UserName@IP-AdresseNAS -p 22

Danach folgt die Aufforderung zur Passwort-Eingabe für den vorher angegebenen User.

4. Führen Sie die folgenden Befehle aus:

wget https://www.j3e.de/linux/convmv/convmv-2.05.tar.gz
tar xzvf convmv-2.05.tar.gz
sudo cp ./convmv-2.05/convmv /usr/bin/convmv

Dann sollten Sie in den übergeordneten Ordner/die übergeordneten Dateien wechseln, bei denen Probleme auftreten, und den Befehl ausführen:

sudo convmv -r -f utf8 -t utf8 --nfc .

Dies ist der Befehl für den Testlauf. Wenn alles gut geht, also ohne Fehler, dann sollten Sie folgendes ausführen:

sudo convmv -r -f utf8 -t utf8 --nfc --notest .

Das war’s. Dateien und Ordner sollten komplett wieder sichtbar werden.

Happy Listening!

Quelle: https://www.reddit.com/r/synology/comments/e7a8hw/i_found_a_proper_fix_for_the_issue_where_files/

Nachtrag: Einige werden sich fragen, ob nicht das neue, aktuelle Dateisystem von Apple namens APFS dem ein Ende bereiten wird. Ja und nein. Mit APFS wird die Kodierung auf die Software-Ebene verlagert, aber gerade dadurch könnte das Chaos noch größer werden… Dieser Artikel beleuchtet diese Entwicklung.

Schreibe einen Kommentar