Ich muss mir heute mal meinen Frust über die schlechte Qualität der Synology-Disk Station Manager (DSM)-Software vom Leib schreiben.

Seit ich Synology-Produkte einsetze — immerhin seit mehr als fünfeinhalb Jahren (DS212+, DS414, DS415+, DS916+, wir reden hier über insgesamt mehr als 1.800 EUR, die nur die “nackten” Geräte gekostet haben!) — ärgere ich mich immer wieder über geradezu stümperhafte Implementierungen von bestimmten Funktionen. Und was dem Ganzen dann die Krone aufsetzt ist der geradezu unverschämt reagierende Synology-Support, der Bugs einfach nicht als Bugs akzeptiert, sondern “gerne in meinem Namen einen Change Request einreicht, aber ob und wann der implementiert wird können wir nicht sagen”. Oder teilweise geradezu dämliche Workarounds als “Lösung” vorschlägt, statt das Problem richtig zu lösen. 🙁

Damit wir uns nicht falsch verstehen: Die absoluten Grundfunktionen (Dateiserver über SMB, CIFS, AFP) funktionieren selbstredend problemlos. Aber dabei ist ja auch nichts falsch zu machen. Synology übernimmt einfach die bekannten und bewährten Open Source-Dienste, wie z. B. Samba. Aber bei fast allem anderen, was Synology “oben drauf gesetzt” hat, gibt es Probleme. Die unten beispielhaft geschilderten Probleme lassen sich allesamt im Netz wieder finden. Unzählige Kunden leider unter diesen Problemen, aber Synology lässt ihre Kunden “im Regen stehen”!

Einige Beispiele von Problemen der letzten Jahre, die ich gegenüber Synology reklamiert habe, die aber bis heute nicht beseitigt sind:

• Hard Disk Hibernation: Ein Drama! Synology kriegt’s einfach nicht hin. Die Geräte wachen einfach immer wieder auf, selbst wenn man das Netzwerkkabel abzieht (so dass klar ist, dass dieses Problem nicht “fremdverursacht” ist, also durch Netzwerkpakete von LAN-Clients). Einfach mal  in den Synology-Foren lesen, es gibt zahllose Kunden die sich darüber beschweren.
• Bei manchen Geräten laufen die Lüfter, während das Gerät im Hibernation-Mode ist. Es gibt keine vernünftige Erklärung dafür, warum das so sein sollte. Die CPU braucht im Tiefschlaf keine Kühlung! Das Problem verschwindet auch manchmal und tritt dann plötzlich wieder auf.
• Log Center: Ich möchte Logs der Synology an meinen Intranet-Server schicken, damit ich “im Falle eines Falles” immer noch eine Kopie habe. Kernel-Logs, die mir beispielsweise Hardware-Defekte anzeigen können, werden trotz mehrfacher Reklamation vor mehr als vier Jahren nach wie vor nicht übertragen.
• Video Station: Ich hatte zwei DVB-T-Dongles im Einsatz. Immer wieder nach einem Update war plötzlich eins der beiden Geräte nicht mehr supportet, dann plötzlich doch wieder. Eines der Dongles hat die Synology zum Absturz gebracht (Kernel Panic). Lapidare Empfehlung des Supports: Dongle entfernen und nicht mehr verwenden! 🙁 Als ich das zurückwies und eine andere Lösung verlangte, wollte der Support Remote-Zugriff auf mein NAS. Dies lehne ich aus Sicherheitsgründen kategorisch ab. Ich bot an, als Linux-Experte die gewünschten Logfiles zu senden oder erforderliche Tests selbst durchzuführen. Dies wurde abgelehnt, der Support-Case wurde geschlossen.
• CloudSync: Da ich als Amazon Prime-Kunde unbegrenzt viele “Fotos” speichern darf, wollte ich alle meine Fotos (über 400 GB) dort hochladen. Also einen Task eingerichtet, der nur “Images” hochladen soll. Ausweislich der File-Extensions, die unter “Images” gelistet werden, hätten dabei nicht die Adobe Lightroom XMP-Sidecar-Files hochgeladen werden dürfen — wurden sie aber dennoch. Synology gesteht nicht ein, dass es sich um einen Bug handelt, sondern empfiehlt einen Work-Around. Der Bug existiert seit mindestens drei Jahren.
• UTC als Zeitzone: Im professionellen Bereich wird häufig UTC als Zeitzone eingesetzt, weil es dort keinen “Zeitsprung” beim Umstellung zwischen Sommer- und Winterzeit gibt. Dies habe ich vor mehr als dreieinhalb Jahren eingefordert, nach wie vor ist das jedoch nicht möglich.
• Hyper Backup: Ich sichere die wichtigsten Shares auf eine externe USB3-Platte, die ich nur für diesen Zweck benutze. Diese Platte lief nun über. Alte Backup-Versionen löschen dauert teilweise eine Stunde pro Version, manchmal sogar länger. Wenn ich also eine größere Anzahl von Backupversionen löschen wollte, war die externe Platte für Tage belegt, und es konnte kein Backup während der Zeit laufen.
  Mittlerweile bin ich so weit, dass ich 100 Versionen gelöscht habe, trotzdem kann kein Backup mehr durchgeführt werden, weil jedesmal durch das aktuelle Backup die Platte wieder überläuft. Es gibt keine Möglichkeit herauszufinden, was Hyper Backup überhaupt beim aktuellen Backuplauf sichern will. Ebenso gibt es keine Möglichkeit herauszufinden, was gesichert wurde.
  Weiterhin ist das Logging unterirdisch und völlig unbrauchbar. Beispiel: “Failed to run backup integrity check.” Ja, schön, interessant — aber warum??? Was ging schief, was muss ich tun um das in Zukunft zu verhindern?!
• Active Backup for Server: Ich benutze dies seit kurzem als Ersatz für ein “händisch” aufgesetztes cron-gesteuertes Backup meines Intranet-Servers. Beide Verfahren benutzen rsync, beide sind “inkrementell”, trotzdem ist mein “händischer” Backup-Job erheblich schneller (braucht lediglich ca. 1/10 der Zeit) und transferiert auch nur einen Bruchteil der Daten über das Netz. Es scheint, dass Active Backup trotz Wahl von “inkrementell” jedes Mal ein volles Backup macht — jedenfalls deutet das übertragene Volumen sehr stark darauf hin.
  Beim Ausführen eines Backups tritt immer ein Fehler auf (“Processed file count: Error: 1”). Es gibt aber keinerlei Möglichkeit herauszufinden, welcher Fehler dabei passiert ist. Es gibt auch keinerlei Möglichkeit herauszufinden, welche Dateien inkrementell seit dem letzten Backuplauf übertragen wurden.
  In der Übersicht der bestehenden Backup-Tasks gibt es nicht einmal die Möglichkeit zu erkennen, um welche Art von Task es sich handelt: Multi-Versioned, Mirroring, Incremental. Selbst wenn man bei Details > Log in die Logdatein guckt, ist das nicht ersichtlich.
• Desktop-Logging für Backups ist nicht vernünftig konfigurierbar. Ich möchte in dem DSM-Desktop erfolgreiche Backups im “Event Viewer” nicht angezeigt bekommen, sondern nur solche, bei denen Probleme aufgetreten sind. Leider lässt sich dies einfach nicht einstellen, DSM informiert mich immer wieder, dass das Backup erfolgreich war (was ja den “Normalzustand” darstellt und daher nicht von Interesse ist!).

Weitere Probleme, die mir aufgefallen sind, die ich aber bisher noch nicht gemeldet habe, weil das ohnehin fruchtlos wäre:

• “Snapshot Replication”-Applet: Die Erstellung von Snapshots scheitert gelegentlich. Warum das passiert ist nicht herauszubekommen. Im Bereich “Log” innerhalb des “Snapshot Replication”-Applets erscheint lediglich die Meldung, dass der Snapshot nicht erzeugt werden konnte, aber nicht warum: “Failed to take a shared folder snapshot from share [homes] by [scheduler]. (Operation failed)”
  Schaut man dann in /var/log/messages, so findet man dann Folgendes:

  2018-02-17T03:00:05+01:00 nas1 synosharesnapshot: snapshot_meta.c:161 Failed to add section [GMT-2018.02.17-02.00.03] to file [/volume1/@sharesnap/@homes.meta], because section is exist.[0x2300 snapshot_meta.c:160]
  2018-02-17T03:00:05+01:00 nas1 synosharesnapshot: snapshot_create.c:301 Failed to add metadata for share [homes], snapshot [GMT-2018.02.17-02.00.03] [0x2300 snapshot_meta.c:160]
  2018-02-17T03:00:06+01:00 nas1 synosharesnapshot: synosharesnapshot_sched.c:57 Failed to create snapshot for share [homes] with scheduler.[0x2300 snapshot_create.c:349]
  2018-02-17T03:00:07+01:00 nas1 img_backup: (11621) [info] snapshot.cpp:328 take share [homes] backup snapshot [/volume1/@sharesnap/homes/GMT-2018.02.17-02.00.03]
  

  Wie man sieht, kommen sich scheinbar “synosharesnapshot” (Snapshot Replication) und “img_backup” (Hyper Backup) “in die Quere”. Es handelt sich also nicht wirklich um ein Problem, aber woher soll man das ohne nähere Untersuchung wissen? Einfach Warnungen oder Fehler ignorieren, da man als “einfacher Benutzer” ohnehin nicht raus kriegt, was passiert?!

• Im Bereich “Log” innerhalb des “Snapshot Replication”-Applets kann man nicht nach Log-Level filtern. Möchte man sich also einen Überblick verschaffen was es für Probleme gegeben hat, so bleibt einem nichts anderes übrig als das Event Log vollständig durchzuscrollen.

Diese ganzen Einschränkungen machen einen (semi-) professionellen Einsatz von Synology-NAS-Geräten unmöglich. Es ist für mich absolut unverständlich, dass sich Synology hartnäckig weigert, absolute Standardfunktionen, wie zum Beispiel vernünftiges Logging, einzubauen. Stattdessen konzentriert man sich lieber darauf, ständig neue Features einzubauen, die aber ohnehin nicht vernünftig funktionieren.

“Masse statt Klasse” scheint das Motto zu sein bei Synology.

Ich werde in Zukunft jedenfalls keine Synology-Geräte mehr empfehlen, sondern stattdessen lieber HP ProLiant MicroServer, zum Beispiel dieses Gerät. Die Hardware ist deutlich besser, und zusammen mit einer Debian-Installation erhält man ein Gespann, welches selbst professionelle Anforderungen en passant erfüllt!