Spaß mit NAS – oder: Die Sorgen des Rundum-Sorglos-Paketes QNAP TS-253D

Zuerst einmal Entschuldigung für das Wortspiel im Titel! Und eigentlich müsste es inzwischen “Kein Spaß mit NAS” heißen – aber der Reihe nach. Es war einst eine Zeit, in der ich meine Rechner selbst zusammengeschraubt habe. Diese ist jedoch schon länger vorbei, denn spätestens beim Montieren der CPU mitsamt Lüfter und irgend welchen Wärmeleitpads war bei mir eine gewisse Spaßgrenze erreicht. Auch die (gebraucht gekauften) Server habe ich nur noch mit neuen Festplatten und teilweise mit mehr RAM bestückt, ab und wann muss ein Lüfter ausgetauscht werden, aber auch das ist üblicherweise nur eine Aktion von wenigen Minuten. Lieber kümmere ich mich um die darauf laufende Software.

Spaß mit NAS – openmediavault!

So läuft seit Jahren auf einigen virtuellen Maschinen die NAS-Distribution openmediavault, eine auf Debian basierende Lösung für Netzwerkspeicher. Damit hatte ich bisher auch überhaupt keine Probleme, openmediavault ist pflegeleicht, ab und wann werden Updates eingespielt, ggf. muss mal auf eine neue Version upgraded werden, aber auch das war bislang keine besondere Herausforderung. Mit openmediavault verwandelt sich die schnöde VM also zu einem per Admin-GUI bedienbaren NAS, das mir Netzwerkspeicher zur Verfügung stellt. Diesen nutze ich für alle Daten die zumindest etwas sicherer als auf der lokalen Festplatte gespeichert werden sollen, etwa Fotos, Archive, Musik etc.. Aber da das RAID des Host-Systems wie wir alle wissen natürlich kein Backup ersetzt, wollte ich endlich einmal die bekannte 3-2-1-Regel umsetzen, also drei Datenkopien auf zwei Datenträgern, davon eine außer Haus.

Backups, aber richtig!

Aufgrund der sehr guten Erfahrungen mit openmediavault bestand die erste Idee darin, sich ein kleines, gebrauchtes System, etwa einen HP Microserver zuzulegen, diesen mit Festplatten zu bestücken und darauf die NAS-Distribution zu installieren. Doch im Gegensatz zum Heise-Bauvorschlag hätte ich lieber auf einen HP Microserver ab Generation 8 (Gen8) zurück gegriffen, deren Preise sich jedoch mit vernünftiger Ausstattung gebraucht nach wie vor um die 400,- EUR bewegen. Für einen nur wenig höheren Betrag erhält man bereits NAS-Systeme bekannter Hersteller wie QNAP oder Synology, die ein Rundum-Sorglos-Paket versprechen. Neben dem zweifellos schicken, weil sehr kleinen Gehäuse, das sich auch mal schnell irgendwo hin mitnehmen lässt, sollte die darauf laufende Software insbesondere für Backup-Zwecke sehr gut geeignet sein, schließlich ist das eine Kernfunktionalität jener Systeme. Dahinter verbirgt sich natürlich ebenfalls ein Linux-System, aber da das Thema “Backup” von vornherein mit wenig Spaß verbunden ist, sollten die Aufgaben wenigstens leicht von der Hand gehen. Und da ich diesmal nur so wenig wie möglich “basteln” wollte, entschied ich mich zum Kauf des NAS QNAP TS-253D.

Das QNAP NAS sollte somit die erste Instanz in der Backup-Kette darstellen, d.h. alle Daten der openmediavault-Server speichern, damit eine unabhängige Kopie vorhanden ist. Diese befindet sich zwar noch am ungefähr selben Ort, ist aber ansonsten getrennt von den übrigen Servern. In einem nächsten Schritt sollten die Daten dann entweder auf externe Festplatten zur Verwahrung an einem anderen Ort oder auf externem Cloud-Speicher gesichert werden. Für Letzteres nutze ich momentan sowohl Backblaze B2 Object Storage als auch eine Hetzner Storage Box, wobei an beiden Orten die Daten selbstverständlich verschlüsselt werden.

Backups mit NAS QNAP TS-253D

Zurück zum QNAP NAS – darauf sollten alle Daten der openmediavault-Server gespeichert werden. Da openmediavault bereits im Netzwerk Samba-Shares zur Verfügung stellt, sollte sich das QNAP NAS einfach dieser bedienen und jeweils nachts einen Backup-Lauf der Samba-Shares durchführen. Das interne Backup dient damit vor allem dazu, eine gewisse Sicherheit vor Bedienungs-Fehlern zu geben. Denn wenn z.B. versehentlich eine Datei im Netzwerkspeicher gelöscht wird, ist sie eben weg, unabhängig davon, ob sich darunter ein RAID befindet oder nicht. Und falls ein Verschlüsselungs-Trojaner zuschlägt, würde er zumindest auf ein permanent gemountetes Verzeichnis des openmediavault-NAS zugreifen können, während das QNAP-NAS davon unabhängig ist. Demgegenüber steht ein Backup mit Versionierung, um etwa Zugriff auf ältere Dateien zu erhalten. Diese wird bei mir aktuell bei der externen Sicherung durchgeführt, zum Einsatz kommt dabei das Tool Restic, das auch für das QNAP-Betriebssystem QTS zur Verfügung steht, entweder direkt als qpkg-Paket installiert werden kann oder in einem Docker-Container läuft.

Das Tool der Wahl: Hybrid Backup Sync (HBS3)

Das mit vielen Buzzwords beschriebene Backup-Tool von QNAP nennt sich “Hybrid Backup Sync” und lag zum Zeitpunkt des Kaufs mit der Firmware QTS 4.4.2 in der Version 3.0.x vor. QNAP selbst nennt es kurz “HBS3”, weshalb es auch im Folgenden so bezeichnet wird. HBS3 ist quasi die eierlegende Wollmilchsau des Backups, wobei ich gar nicht auf viele Besonderheiten zurückgreife, sondern einfach die als Samba-Share von openmediavault zur Verfügung gestellten Verzeichnisse auf das QNAP-NAS kopieren wollte. Im ersten Schritt wurden dazu auf dem openmediavault-System User-Accounts angelegt, denen ausschließlich Lese-Zugriff gestattet war. Schließlich muss HBS3 nur sichern, soll aber niemals die Möglichkeit besitzen, die Original-Daten zu verändern. Um eine gewisse Strukturierung zu ermöglichen, wurden auch auf dem QNAP-Gerät Backup-User-Accounts angelegt, deren Home-Verzeichnisse mit den zu sichernden Samba-Share-Namen korrespondieren. So wird z.B. das Samba-Share namens “oldies” auf dem Server “spandau” (User “ubakoldies”) in das Verzeichnis “homes/ubaknas/oldies” auf dem QNAP-NAS kopiert, hier heißt der User “ubaknas”, der sich für zwei thematisch ähnliche Backup-Verzeichnisse zuständig zeigt.

In der HBS3-Nomenklatur existieren so genannte Backup-“Aufträge”, wobei “Meine Aufträge” auf dem NAS selbst laufen und “Eingehende Aufträge” auf einem anderen System laufen und das NAS als Ziel beinhalten. Die Bezeichnungen muten teilweise etwas seltsam an, es hat mich auch erst einiges Rätselraten gekostet, um zu entdecken, dass das von mir geplante “Pull”-Verfahren, d.h. das QNAP-NAS soll sich auf dem Samba-Server einloggen und von dort die Dateien in ein lokales Ziel-Verzeichnis kopieren, einen “Aktiven Synchronisierungsauftrag” darstellt. Doch diese kleinen Hürden waren zu überwinden und so wurden diese Aufträge, also Backups, jede Nacht zu bestimmten Uhrzeiten völlig problemlos ausgeführt.

Nur einmal, als mein interner DNS aufgrund eines vorherigen Stromausfalls streikte, hatte das QNAP TS-253D Probleme, die Samba-Server zu erreichen – dies war aber nachvollziehbar und verständlich. Dank des Benachrichtigungssystems bekam ich immerhin (ein wenig später, als die DNS-Server wieder in Ordnung waren) eine Mail und wurde informiert, dass etwas schief gelaufen war. Insofern war ich bis dahin zufrieden – die nächtlichen Backups funktionierten, und falls nicht, erhielt ich per Mail eine entsprechende Mitteilung. Ein- oder zweimal verlangte QNAP nach einem Upgrade der Firmware, auch HBS3 selbst wurde von mir immer bei Bedarf auf die jeweils aktuelle Version updated. Soweit lief also alles wie gewünscht, und auch mit der Geschwindigkeit war ich zufrieden, die zur Verfügung stehende Netzwerk-Bandbreite wurde jedenfalls perfekt ausgenutzt.

HBS3 – kaputt!

Um es vorweg zu nehmen – diese Zufriedenheit sollte sich eines Tages ändern. Und zwar wollte HBS3 wieder einmal auf eine neue Version aktualisiert werden, zuvor war eine Version 3.0.200805 installiert, mit der darauf folgenden und somit aktuellen Version hatte sich das Versionierungsschema geändert, so dass die Versionsnummer nun plötzlich 13.0.0930 lautete. Dabei dachte ich mir noch nichts Besonderes, denn die sonstigen Änderungen im Changelog versprachen allenfalls Fehlerbehebungen und für mich eher uninteressante Änderungen.

Doch in der Nacht nach dem Update erhielt ich plötzlich Mails aus dem Benachrichtigungssystem, in denen zu lesen war, dass das Backup nicht funktioniert hatte. Diese lauteten wie folgt:

App Name: Hybrid Backup Sync
Category: Custom Job Event
Message: [Hybrid Backup Sync] Failed to complete Sync job: "Backup spandau oldies". Failed to log into Sync Server. Check username and password.. Check logs for more information.

Was war da denn passiert? Ein Blick in die Admin-UI des NAS zeigte das Ausmaß, denn die meisten Backup-Jobs hatten plötzlich Probleme.

Wie in derartigen Fällen üblich, suchte ich zunächst nach einem Problem auf dem openmediavault-System, doch darauf konnte ich wie gewohnt zugreifen. Und an den Zugangsdaten hatte ich nichts geändert. Also befolgte ich den Hinweisen in der Mail, schließlich nahm ich an, dass mir HBS3 mehr über das Problem verraten würde. Leider stellte sich das als Irrtum heraus, denn mehr als “funktioniert nicht” war auch dem Bericht (unter HBS3 – Aufträge – Auftragsname (etwa: “Backup spandau oldies” – Bericht – Protokolle) nicht zu entlocken.

Immerhin wurde ein Fehlercode genannt, die vollständige Meldung lautete:

[Hybrid Backup Sync] Failed to complete Sync job: "Backup spandau oldies". Failed to log into Sync Server. Check username and password. Error code: -56

Damit sollte sich doch eigentlich das Problem googlen lassen, oder? Weit gefehlt, zumindest mir ist es nicht gelungen, aufgrund dieses Fehlercodes irgend eine sinnvolle bzw. weitergehende Information zu finden. Um genau zu sein scheint dieser Fehlercode für den User auch völlig irrelevant zu sein. Erwartet hätte ich etwa eine Liste von Fehlercodes, die QNAP veröffentlicht, und damit einher gehend etwaige Lösungsmöglichkeiten darlegt. Doch nichts dergleichen ließ sich finden. Aber wozu dann dieser nichtssagende Fehlercode? Für mich als Anwender einfach nur sinnlos.

Kein Spaß mit Logfiles von HBS3

Doch im Protokoll-Tab findet sich noch der Button “Speichern”. Einmal gedrückt, wird ein Zip-File mit umfangreicheren Logs gespeichert. Im weiteren Verlauf hatte mich der Support auch gebeten, ein HBS3-Log zu erstellen und diese Datei zur Verfügung zu stellen, dazu gleich mehr. Das Log lässt sich ebenfalls für alle HBS3-Aufträge erstellen, indem man auf die “drei Punkte” in der rechten oberen Ecke klickt und dort “Fehlerbericht” wählt. Zwar empfand ich es nicht wirklich als meine Aufgabe, diese Logs zu durchforsten, aber man interessiert sich ja nun doch irgendwie auch dafür… Also habe ich das Zip-File entpackt und den einen oder anderen Blick hinein geworfen. Das Fatale – und für mich Unglaubliche – dabei: Egal in welche der Log-Dateien ich schaute, es wurden darin auch nicht mehr Informationen bzw. weitere Details preisgegeben! Es wiederholte sich:

system,c703c6f6-d5d8-11ea-93e2-245ebe3e60e0,error,2020-10-18T03:50:04.050358+02:00,"[Hybrid Backup Sync] Failed to complete Sync job: "Backup spandau oldies". Failed to log into Sync Server. Check username and password. Error code: -56"

Oder:

3076,  2,2020-10-29,13:30:03,System,127.0.0.1,localhost,[Hybrid Backup Sync] Failed to complete Sync job: "Backup spandau oldies". Failed to log into Sync Server. Check username and password. Error code: -56, 41,1603974603,A200,Hybrid Backup Sync,C002,Job Status,

Und wieder:

[2020/10/29 13:34:11] Maximum retry times: 5; Retry interval in seconds: 180; Connection timeout in seconds: 60; Current retry number: 0.
[2020/10/29 13:34:14] # ERROR: Unable to log onto Sync Server: Invalid username or password.

Ja, damit ließ sich so richtig viel anfangen. Oder eben auch nicht…

Warum aber nun plötzlich Username und Passwort nicht mehr korrekt sein sollten, darüber verriet mir kein QNAP-Logfile etwas. Zumindest nicht auf den ersten Blick, aber zum Fehlercode “-56” fand sich auch hier nichts.

Ursachenforschung

Aber warum konnte sich HBS3 nicht mehr auf dem Samba-Share von openmediavault einloggen?

Ein wenig stutzig wurde ich, als ich bemerkte, dass HBS3 auf eine ältere Version von openmediavault anscheinend doch zugreifen konnte. Die Backup-Jobs, die Daten von einem (eigentlich schon außer Betrieb genommenen) openmediavault-Server mit Release 3.0.99, Codename “Erasmus” synchronisierten, funktionierten zu meiner Verwunderung auch weiterhin. Nicht jedoch der Zugriff auf die Samba-Shares unter openmediavault Version 5.5.12-1, Codename “Usul”.

Nach den rein gar nicht aussagekräftigen Logs von HBS3 habe ich mir die Log-Files von openmediavault bzw. dem zugrunde liegenden Debian-System näher angeschaut. Dort wurde ich sehr schnell fündig:

Oct 18 09:02:30 spandau smbd[4211]: [2020/10/18 09:02:30.994155,  2] ../libcli/auth/ntlm_check.c:430(ntlm_password_check)
Oct 18 09:02:30 spandau smbd[4211]:   ntlm_password_check: NTLMv1 passwords NOT PERMITTED for user ubakoldies
Oct 18 09:02:31 spandau smbd[4211]: [2020/10/18 09:02:30.995360,  2] ../source3/auth/auth.c:334(auth_check_ntlm_password)
Oct 18 09:02:31 spandau smbd[4211]:   check_ntlm_password:  Authentication for user [ubakoldies] -> [ubakoldies] FAILED with error NT_STATUS_WRONG_PASSWORD, authoritative=1
Oct 18 09:02:31 spandau smbd[4211]: [2020/10/18 09:02:30.995678,  2] ../auth/auth_log.c:610(log_authentication_event_human_readable)
Oct 18 09:02:31 spandau smbd[4211]:   Auth: [SMB,(null)] user []\[geschke] at [So, 18 Okt 2020 09:02:30.995608 CEST] with [NTLMv1] status [NT_STATUS_WRONG_PASSWORD] workstation [192.168.10.15] remote host [ipv4:192.168.10.15:53219] mapped to []\[ubakoldies]. local host [ipv4:192.168.10.108:445] Oct 18 09:02:31 spandau smbd[4211]:   
{"timestamp": "2020-10-18T09:02:30.996134+0200", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 0}, 
"status": "NT_STATUS_WRONG_PASSWORD", "localAddress": "ipv4:192.168.10.108:445", "remoteAddress": "ipv4:192.168.10.15:53219", 
"serviceDescription": "SMB", "authDescription": null, "clientDomain": "", "clientAccount": "ubakoldies", 
"workstation": "192.168.10.15", "becameAccount": null, "becameDomain": null, "becameSid": null, 
"mappedAccount": "ubakoldies", "mappedDomain": "", "netlogonComputer": null, "netlogonTrustAccount": null,
"netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv1", "duration": 9695}}

Eine Suche von “ntlm_password_check: NTLMv1 passwords NOT PERMITTED” förderte dann interessante Details zutage – das Problem lag anscheinend in der Nutzung eines “old clients“, also eine veralteten Version der zugreifenden Software.

In diesen Momenten durchfuhr mich des Öfteren ein gar nicht so leises “WTF?!?“…

Den vorgeschlagenen Workaround, bei den Samba-Einstellungen etwas zu verändern, damit etwa alte Windows XP (sic!) Clients damit zurecht kommen (siehe Samba-Mailingliste), wollte ich nicht durchführen – schließlich hatte die Version HBS3 3.0.200805 problemlos funktioniert, die neuere HBS3 13.0.0930 jedoch urplötzlich und unverständlicherweise nicht mehr.  Außerdem hätte das eine Änderung für jedes openmediavault-System bedeutet, ggf. bei Upgrades wieder zu prüfen etc.. Ich muss wohl kaum erwähnen, dass im Changelog von HBS3 nicht die Spur von irgendeinem Downgrade auf eine alte SMB-Library zu lesen ist…

Natürlich hatte ich auch versucht, auf dem QNAP NAS mit HBS3 einen neuen Auftrag bzw. einen neuen Remote Server “Speicherplatz” (auch hier setzt sich die fragwürdige Nomenklatur fort) einzurichten, d.h. Username und Passwort neu einzugeben, neu zu speichern, evlt. hatte sich ja das Speicherformat geändert oder ähnliches. Doch auch das führte nicht zum Erfolg, bereits der erste Zugriffsversuch zwecks Test scheiterte, ebenso wie der darauf basierende Backup-Auftrag.

HBS3 Downgrade

Glücklicherweise fand sich auf der QNAP-Website noch eine ältere Version von HBS3, und zwar in der Software-Library für die ältere Firmware-Fassung 4.4.2 (inzwischen hatte ich die Firmware 4.5.1 installiert). Insofern konnte ich auf HBS3 in Version 3.0.200727 downgraden, worin auch der quasi ultimative Test bestand, denn wenn dies wieder funktionierte, war die Ursache wohl mehr als eindeutig.

Und siehe da – HBS3 Version 3.0.200727 hochgeladen, installiert, getestet, mit Erfolg! Alle Backup-Aufträge funktionierten wieder! Und zwar ohne dass ich irgendwelche Zugangsdaten auf dem QNAP-NAS geändert hatte.

Heißt “Support” nicht “Unterstützung”?

Mit diesen Informationen im Gepäck öffnete ich am 18.10.2020, d.h. am Tag nachdem die Probleme aufgetaucht waren, ein Support-Ticket, indem alle Probleme und deren Lösungen inkl. Angabe der auch hier genannten Log-Einträge von Samba beschrieben wurden. Es sollte über eine Woche dauern, bis jemand antwortet und mich um die Zusendung der System-Logs (erstellt mit dem Helpdesk-Tool) bat. Ebenfalls interessierte er sich für die Version des Samba-Servers. Also erstellte ich das entsprechende Log und nannte die Versionsnummern von openmediavault:

================================================================================
= OS/Debian information
================================================================================

No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster

================================================================================
= openmediavault information
================================================================================

Release: 5.5.12-1
Codename: Usul

================================================================================
= System information
================================================================================

Linux spandau.geschke.net 5.8.0-0.bpo.2-amd64 #1 SMP Debian 5.8.10-1~bpo10+1 (2020-09-26) x86_64 GNU/Linux
[...] 
 samba 2:4.9.5+dfsg-5+deb10u1 amd64 SMB/CIFS file, print, and login server for Unix
 samba-common 2:4.9.5+dfsg-5+deb10u1 all common files used by both the Samba server and client
 samba-common-bin 2:4.9.5+dfsg-5+deb10u1 amd64 Samba common files used by both the server and the client
 samba-libs:amd64 2:4.9.5+dfsg-5+deb10u1 amd64 Samba core libraries
 samba-vfs-modules:amd64 2:4.9.5+dfsg-5+deb10u1 amd64 Samba Virtual FileSystem plugins

Den Hinweis, dass die Logs nicht wirklich nützlich sein würden, da ich bereits auf die ältere Version zurückgegangen war, vergaß ich natürlich ebenfalls nicht.

Am selben Tag wurde ich noch um die Zusendung des HBS3-Fehlerberichts gebeten. Auch diesen stellte ich noch taggleich zur Verfügung. Bei den vielen Logs und Informationen, die ich bereits genannt hatte, sollte sich doch etwas finden lassen, oder? Beispielsweise könnte man ein openmediavault schnell in einer VM oder gar aus einem Docker-Image herstellen, ein Samba-Share konfigurieren, einen User anlegen und mittels HBS3 darauf zugreifen? Ist ja auch nur eine Idee, aber so hätte ich es vermutlich gemacht – und dem fehlerberichtenden User diese Schritte auch mitgeteilt, insbesondere dann, wenn man im Dunkeln tappen würde bzw. der Fehler nicht reproduzierbar gewesen wäre.

Alles für nichts

Doch stattdessen folgte weitere drei Tage später eine Mail, in der ich gebeten wurde, die aktuelle Version von HBS3 zu installieren und danach mittels der Helpdesk-Anwendung einen Remote-Zugang auf das NAS zu gewähren. Also schön – daraufhin habe ich HBS3 updated, alles erneut getestet, und bin zu denselben Ergebnissen gekommen wie hier beschrieben. Teilweise stammen die Log-Auszüge in diesem Artikel übrigens auch von den heutigen Tests. Bevor ich jedoch Remote-Zugang gestatte, habe ich mir die Service-Bedingungen durchgelesen. Diese sagen im Prinzip – bezogen auf das NAS – Folgendes aus: “Wir können alles, aber übernehmen die Verantwortung / Haftung für nichts“.

Sorry, aber nö. Nein, Danke. Wirklich nicht. Darüber hinaus brauche ich keinen technischen Support, weil ich vielleicht die Software nicht bedienen kann oder ähnliches. Letztlich hätte ich das System als kompromittiert ansehen müssen, also entweder vorher alle Daten löschen müssen (was dem Sinn eines Tests widersprechen würde), oder hinterher alles neu einrichten. Insbesondere hätten die zugreifenden Personen auch einen Zugang für den openmediavault-Server benötigt, denn wie hätte sich sonst das Problem nachvollziehen lassen? Ich habe dies also abgelehnt, jedoch verbunden mit dem Hinweis, dass ich gerne alle notwendigen Logs (falls sich im System noch welche verbergen sollten) bereitstelle oder dass ich auch anrufbar wäre und das NAS nach Anweisung bedienen könnte. Der Remote-Zugang hingegen hätte für mich das NAS schlagartig wertlos werden lassen. Immerhin laufen die Backup-Prozesse ja wieder, wenngleich mit der veralteten Version von HBS3.

Quo vadis, QNAP?

Ende offen – ich bin gespannt, wie es weiter geht. Meine momentane Bewertung des QNAP NAS TS253-D ist somit zwiegespalten. Einerseits ist es ein kleines, schickes Kistchen, das seine Aufgaben im Prinzip gut erfüllt. Getrübt wird dieser Eindruck natürlich durch die beschriebenen Probleme der neuen Version von HBS3 mit einer halbwegs aktuellen Samba-Version. Der Support war – naja, sagen wir mal sachlich und bemüht, aber bislang nicht hilfreich. Und ich finde es immer noch seltsam, dass es zu derartigen Fehlern kommen kann, aber dies scheint bei QNAP und HBS3 auch nicht das erste Mal zu sein, wie z.B. in Foren-Einträgen zu lesen ist (“Hybrid Backup Sync not working for CIFS/SMB“, “SMB/CIFS backup job stops working“). An der Qualitätssicherung kann bzw. muss QNAP daher definitiv noch arbeiten.

Update 19.11.2020 – Support per TeamViewer

Nachdem wieder ein paar Tage vergangen waren, wurde ich gebeten, noch ein paar – in meinen Augen wenig ertragreiche – Tests durchzuführen, etwa ob ein Mount-Versuch mit anschließendem Login funktioniert. Ich führte die Tests durch, allerdings wiederholte sich das Verhalten – mit der alten Version von HBS3 war der Login möglich, mit der neuen nicht. Also nichts, was nicht bereits bekannt gewesen wäre. Daraufhin wurde ich vom Support-Mitarbeiter gefragt, ob ich mit einer TeamViewer-Sitzung einverstanden wäre, und wenn ja, sollte ich ein paar Termine dafür vorschlagen. Zwar behielt sich QNAP auch dabei das Recht vor, Screenshots oder Aufzeichnungen anzufertigen, aber da mit TeamViewer immerhin der Zugriff in meinem Beisein stattfindet und ich alle Schritte live nachverfolgen und im schlimmsten Falle abbrechen konnte, war ich damit einverstanden. Zuvor wurde mir ein Link zum Download der “TeamViewer Quick Support“-Anwendung bereitgestellt, die ich nur noch starten und kurz vor dem Termin die von der Anwendung generierten Verbindungsdaten, bestehend aus einer ID und einem Passwort ins Support-Ticket eintragen sollte.

Ich sollte vielleicht erwähnen, dass meine bisherigen Erfahrungen mit TeamViewer gegen null tendierten, insofern war ich durchaus gespannt, was mich dabei erwartete. Die TeamViewer-Anwendung hatte ich bereits gestartet, kurz vor dem Termin wollte ich die Zugangsdaten dann ins Ticket eintragen. Etwas überrascht war ich, als mir etwa 40 Minuten vor dem Termin eine Support-Mail gesendet wurde, in ich gebeten wurde, die Zugangsdaten zur Verfügung zu stellen, da die Techniker den Termin eine Stunde vorverlegen mussten. Naja… Also vom zeitlichen Aspekt her empfand ich dies gelinde gesagt ein wenig ungeschickt, zwar befand ich mich bereits am Rechner, aber eine Terminverschiebung sollte man doch etwas früher ankündigen als 20 Minuten nachdem der neue Termin eigentlich begonnen hätte… Aber gut, ich bereitete soweit alles vor, beendete also alle nicht benötigten Anwendungen, ließ das Browser-Fenster für die Admin-UI des NAS geöffnet, übermittelte die Zugangsdaten und harrte der Dinge.

Etwa zehn Minuten später wurde dann die Sitzung gestartet. Zu meiner Überraschung loggte sich anscheinend jemand direkt aus Taiwan ein und sah sich erstmal in der Admin-UI um. Überrascht war ich daher, weil mein Kontakt bis dato vermutlich aus Deutschland stammte, denn alle Support-Tickets waren auf Deutsch beantwortet worden. Aber die Verständigung per Chat funktioniert natürlich auch prima in englischer Sprache. Ebenfalls war ich ein wenig überrascht, dass der QNAP-Mitarbeiter nicht so wirklich Bescheid über den Ticket-Verlauf wusste. Selbstverständlich war die alte, funktionierende Version von HBS3 wieder auf dem QNAP-NAS installiert gewesen, alles andere wäre auch sinnlos und hätte die Anschaffung des NAS ad absurdum geführt. Ich erklärte somit kurz das Verhalten bzgl. alter und neuer Version von HBS3.

Nachdem der Techniker also kurz den Erfolg der Synchronisierung mit der installierten HBS3-Version prüfte, fragte er mich, ob ich einverstanden wäre, wenn er ein neues Binary herunterladen und installieren würde. Ferner sollte ich mich per SSH mit dem QNAP-System verbinden. Ich ließ den Support-Mitarbeiter gewähren, woraufhin er per TeamViewer eine Datei “qsync.static” übermittelte, diese mittels “File Station” auf das NAS brachte und daraufhin in die SSH-Console wechselte. Leider hat er im Lauf dieser Arbeiten auch die Bildschirmauflösung verringert, was ich als furchtbar empfand. Es macht einfach keinen Spaß, hinterher alle Fenster wieder auf die vorherige Größe klöppeln und zu guter Letzt noch die Mausbeschleunigung neu einstellen zu müssen. Dasselbe Phänomen begegnet einem auch immer wieder in Autowerkstätten bzgl. der Sitz-, Lenkrad- und Spiegeleinstellungen. Da wechseln die Mechaniker nur mal die Reifen, verstellen aber für die drei Meter Fahrt vom Parkplatz in die Werkstatthalle mal eben alles, was man zuvor mühselig in gefühlt stundenlanger Arbeit auf die eigenen Bedürfnisse zurechtkonfiguriert hat. Na gut, ich schweife ab…

Jedenfalls hat sich der QNAP-Mitarbeiter (natürlich sind hiermit auch alle Mitarbeiterinnen gemeint, denn wenn mich nicht alles täuscht, würde ich angesichts des in TeamViewer angezeigten Namens tatsächlich auf eine Technikerin tippen) per SSH erstmal ein wenig umgesehen und schließlich die bisherige Version von “RTRR” durch Löschen des bestehenden und Setzen eines symbolischen Links auf das heruntergeladene Binary ersetzt.

Danach wurde es auch für mich spannend – funktionierte die Synchronisierung, oder zeigte sich das von mir beschriebene Verhalten? Und siehe da – die Synchronisierung schlug nun fehl! Der Techniker schaute sich noch einige Logs auf der Console an, ich gab noch Hinweise zu den verwendeten Versionen von Samba, openmediavault, Linux & Co. und fragte, ob ich auf dem openmediavault-NAS evtl. die Samba-Logs wieder aktivieren sollte, um diese bereitstellen zu können, doch nach eigener Aussage kannte sich der Mitarbeiter mit Samba eher weniger gut aus, insofern konnte ich hier nicht weiterhelfen. Ebenfalls betonte ich erneut, es nicht nachvollziehen zu können, weshalb die alte Version von HBS3 mit einer älteren Samba-Version eines älteren openmediavault- bzw. Debian-Systems ebenso zurecht kommt wie mit der aktuellen Variante, während die neue Version von HBS3 ausgerechnet mit der neuen Samba-Fassung Probleme zeigt. Umgekehrt hätte ich es ja verstanden, wenn etwa neuere Clients ältere Server-Versionen nicht mehr unterstützen, aber das von HBS3 gezeigte Verhalten ist mir nach wie vor suspekt.

Nicht minder suspekt empfand ich die vom Mitarbeiter gestellte Frage, warum ich nicht einfach die ältere Version von Samba bzw. openmediavault einsetze, da sich HBS3 mit dieser doch verbinden könne… Ja, warum setzt man wohl keine veralteten Linux-Distributionen ein, die zum Beispiel keine Security-Updates mehr erhalten..? Mal ganz abgesehen davon, dass bei mir mehrere openmediavault-NAS-Systeme im Einsatz sind, jedoch nur ein QNAP-NAS, insofern wäre der Aufwand eines Downgrades um ein Vielfaches höher. Immerhin gab sich der Techniker mit der Antwort zufrieden und schlussfolgerte, dass mir dann die Möglichkeit blieb, wieder die alte HBS3-Version zu nutzen und auf einen Fix zu warten. Zwar ist das im Prinzip genau dasselbe, was ich bereits seit dem Auftreten des Problems gemacht habe, aber wenigstens hatte nun QNAP das Verhalten live gesehen und insofern das Problem bestätigt.

Es bleibt somit mal wieder spannend, wann der vom Techniker in Aussicht gestellte “Fix” denn wohl erscheinen mag. Und nach wie vor ist es mir ein Rätsel, ob ich tatsächlich der Einzige bin, bei dem das Problem in der beschriebenen Form auftaucht. Ist die Verwendung von Linux bzw. Samba, wobei der Inhalt der Samba-Shares von einem QNAP-NAS per Hybrid Backup Sync zwecks Backup synchronisiert wird, so ungewöhnlich? Wird ein derartiges System nur mit Windows-Clients getestet? Wie heißt es so schön – wir bleiben dran…

Update 03.02.2021 – Upgrade, Zeichen und Wunder!

Nun ist einige Zeit vergangen, einige Firmware-Upgrades später habe ich mich nun endlich getraut, auch HBS3 auf die neueste Version zu updaten. Man erinnere sich – Version 13.0.0930 war defekt, es folgten zwei weitere, die letzte trägt die Versionsnummer 15.0.0128 und stammt vom 03.02.2021. Die Version dazwischen hatte ich übersprungen, weil das HBS3-Changelog meiner Ansicht nach nicht wirklich eindeutig Stellung bezieht, vielleicht gehörte der beschriebene Fehler ja zu denjenigen, die QNAP unter “Fixed some minor bugs” subsummiert.

Somit war ich durchaus in gespannter Erwartung, als nach dem Update die erste Synchronisierung ausgeführt wurde. Und tatsächlich – das Problem war gelöst, alle Daten wurden vom openmediavault-System problemlos kopiert! Insofern hat sich die Teamviewer-Sitzung doch letztlich ausbezahlt, QNAP hat sich des Problems angenommen und den versprochenen Fix geliefert.

Für ein paar Stunden war ich tatsächlich versöhnt mit der Welt und absolut zufrieden mit QNAP. Bis, ja bis mich eine Mail vom Log-System erreichte, von wegen die im November gekaufte und damals aktivierte exFAT-Lizenz könne nicht aktiviert werden. Ein kurzer Check in der Admin-UI, anscheinend sind sich das Log-System und das License Center nicht einzig, das Log meint, die Lizenz könne nicht aktiviert werden (über die Details schweigt es sich hingegen aus), während das Tool, das zuständig ist für die Verwaltung der Lizenzen, nur mit sich selbst im Reinen ist und die Lizenz als “gültig” anzeigt. Das nächste Support-Ticket ist erstellt, ich bin erneut sehr gespannt auf die Lösung. Vielleicht werde ich diesmal auch direkt zu den Technikern durchgestellt…

Update 28.02.2021 – schnelles Update, schnelle Lösung

Wie mir der QNAP Support zwei Tage später mitteilte, handelte es sich um einen fehlerhafte Benachrichtigung, einen “FALSE ALARM”. Nach einem Update der License Centers war der Spuk auch tatsächlich vorbei, die Lizenz war auch zu jeder Zeit gültig.