staging.inyokaproject.org

18. Dezember 2019

Oft huschen durch meinen Twitter-Feed ganz interessante Beiträge mit Tipps & Tricks (oder nennt man das nicht schon neumodisch "lifehacks"? – egal). Ein Tipp, den ich euch nicht vorenthalten kann, betrifft diesmal LibreOffice Writer.

Sollen in einem Dokument Absätze verschoben werden, ist das gerne lästige Arbeit. Markieren, Ctrl + X, Ctrl + V. Aber LibreOffice kann das auch einfacher: Ctrl + Alt + arrow up/arrow down. Das Feature kenne ich schon von IntelliJ (hier ist die Kombination Ctrl + Shift + arrow up/arrow down) und möchte es ehrlich gesagt nicht mehr missen.

Einfach mal ausprobieren!

Update (19.12.2019, 14:35 Uhr): wie ich gerade in den Kommentaren höre, liegt auf der gleichen Tastenkombination je nach Desktop Environment eine höherpriorisierte Tastenkombination vom System (GNOME Arbeitsflächen, etc.). (Das fiel mir anfangs nicht auf, da ich auf meinem System viele Tastenkombinationen umgestellt habe.) Hier ist es natürlich sinnvoller, die LibreOffice Tastenkombination (die ich ehrlich gesagt auch nicht an der Stelle so mag, die von IntelliJ gefällt mir da besser) zu ändern. Das geht unter Extras → Anpassen → Tab "Tastatur". Die konkrete Umstellung zeigen folgende Screenshots:

Screenshot LO Tastenkombination umstellen (1)

Tastenkombination in der oberen Liste auswählen, um mit einem Klick auf "Löschen" das Keybinding zu entfernen. Dann in der unteren Suche "Nach oben verschieben" resp. "Nach unten verschieben" suchen und auswählen, dann oben die gewünschte Tastenkombination auswählen und auf "Ändern" klicken. Ist etwas umständlich und erinnert an GUIs aus den 2000ern, funktioniert im Endeffekt aber. :)

Screenshot LO Tastenkombination umstellen (2)

17. Dezember 2019

DNS over HTTPS, kurz: DoH, soll die Sicherheit und Privatsphäre der Nutzer verbessern. Nach Cloudflare hat Mozilla NextDNS als weiteren Partner gewonnen.

Was ist DNS over HTTPS?

Wikipedia beschreibt DNS over HTTPS mit den folgenden Worten:

DNS over HTTPS (DoH) ist ein Protokoll zur Durchführung einer DNS-Auflösung über das HTTPS-Protokoll. Das Ziel ist es, die Privatsphäre und Sicherheit der Benutzer zu erhöhen, indem das Abhören und Manipulieren von DNS-Daten durch Man-in-the-Middle-Angriffe verhindert wird. Neben der Verbesserung der Sicherheit sind weitere Ziele von DNS über HTTPS, die Leistung zu verbessern und DNS-basierte Zensurmaßnahmen zu verhindern. DNS over HTTPS wurde am 19. Oktober 2018 als RFC 8484 standardisiert.

Wikipedia

DNS over HTTPS in Firefox

Bereits 2017 begann Mozilla die Arbeiten an DNS over HTTPS. Vor wenigen Wochen hat Mozilla schließlich die offizielle Ausrollung für erste Firefox-Nutzer in den USA begonnen.

Mozilla setzt dabei standardmäßig auf 1.1.1.1 von Cloudflare als DNS-Resolver. Der Nutzer kann in den Firefox-Einstellungen aber auch jeden anderen DNS-Anbieter eintragen oder das Feature komplett deaktivieren.

Cloudflare soll nicht Mozillas einziger Partner bleiben. Im Rahmen seines Trusted Recursive Resolvers-Programms (TRR) sucht Mozilla nach weiteren vertrauenswürdigen Partnern. Dafür müssen strenge Vorgaben erfüllt werden. Beispielsweise dürfen Daten nicht länger als 24 Stunden aufbewahrt werden und die Weitergabe an Dritte ist untersagt. Ebenso ist eine öffentliche Datenschutzerklärung verpflichtend, welche beschreibt, welche Daten anfallen und wie mit diesen umgegangen wird. Sofern vom Gesetzgeber nicht anders verlangt ist auch die Modifizierung oder Blockierung des DNS strengstens untersagt – außer natürlich, der Nutzer willigt explizit in eine Filterung ein, wie es zum Beispiel bei einer Kindersicherung der Fall ist.

Wie Mozilla heute angekündigt hat, hat man nach Cloudflare nun auch NextDNS als Partner für DoH in Firefox gewinnen können. NextDNS ist ein noch sehr junger DNS-Anbieter, der erst im Mai dieses Jahres vom Dailymotion-Gründer sowie einem langjährigen Dailymotion-Mitarbeiter gegründet worden ist.

Der Beitrag NextDNS ist neuer Partner für DNS over HTTPS in Firefox erschien zuerst auf soeren-hentzschel.at.

15. Dezember 2019

Für den Einsatz von Linux im Server- und Desktopbereich gibt es nur wenige belastbare Zahlen. Die meisten Anwender lehnen Tracking ab und nur wenige Distributionen erheben überhaupt Anwenderzahlen. Dementsprechend halten sich viele Mythen und jeder kann aus seiner persönlichen Wahrnehmung heraus Ansichten postulieren.

Vor einigen Jahren habe ich mich in zwei Artikel bereits damit befasst:

Die Zahlen beruhten und beruhen auf Debian und Ubuntu, weil lediglich diese beiden Distributionen überhaupt systematisch die Nutzung der Pakete und anderer Systeminformationen erheben. Beide auf freiwilliger Basis, was Verzerrungen und erhebliche Abweichungen von der Realität nicht ausschließt, aber wir haben keine anderen Zahlen.

Mich hat kürzlich interessiert wie sich das Thema in den vergangenen Jahren entwickelt hat. 

Debian

Die Erhebung ist bei Debian relativ einfach, weil alle Desktopumgebungen bis auf KDE Plasma ein zentrales Session-Paket haben, das für die Funktionsfähigkeit installiert sein muss.

Zu sehen ist, dass GNOME immer noch unangefochtener Spitzenreiter ist. Vermutlich wirken sich hier die Default-Settings bei der Installation aus. Allerdings mit Verlusten, wohingegen alle anderen Desktopumgebungen leicht dazu gewinnen. Insbesondere KDE Plasma scheint sich langsam aus dem Tal der Tränen, in das es nach den Umbrüchen der Versionen 4 und 5 gestürzt ist, heraus zu kämpfen.

Als kleine Ergänzung übrigens ein Vergleich mit dem zentralen libc6 Paket.

Ich war überrascht wie viele messbare Debian-Installation einen Desktop installiert haben. Schließlich galt und gilt Debian primär als Serverbetriebssystem.

Insgesamt sind die Zahlen sehr gering, was umso mehr überrascht, da Debian in der Installationsroutine explizit um die Teilnahme an Popcon bittet.

Ubuntu

Bei Ubuntu erfolgte die Zählung über die zentralen -desktop Pakete. Seit 18.04 erhebt Canonical daneben noch weitere Zahlen, die aber nicht der Allgemeinheit zur Verfügung stehen. Das ist besonders bedauerlich, weil laut deren Erhebung zumindest die Nutzer des Haupt-Derivats Ubuntu zu 66% der Erhebung zustimmen. Die Datenmenge dürfte daher um ein vielfaches größer sein.

Ubuntu 2.009.373
Kubuntu 268.733
Xubuntu 131.543
Lubuntu 26.857
Ubuntu MATE 543
Ubuntu Budgie 77

Die absurd geringen Zahlen bei MATE und Budgie lassen mich hier aber einen Denk- oder Messfehler vermuten. Allerdings bitten Canonical auch nicht aktiv um die Teilnahme an Popcon, sondern der Anwender muss dies in den Software-Properties dezidiert aktivieren. Ein Vergleich mit den "Desktop Metrics" ist leider nicht möglich, weil die von Canonical publizierten Grafiken lediglich Prozentwerte beinhalten (ein Schelm, wer böses dabei denkt...)

Auffällig ist wie gering die Zahlen im Vergleich zu 2015 angestiegen sind. Die Ursachen mögen in der gewachsenen Popularität anderer Distribution liegen, aber der Linux Markt scheint insgesamt ziemlich gesättigt zu sein. Die große Migrationswelle mit dem Supportende von Windows 7, die von manchen herbei geredet wird, sehe ich nicht kommen.

Das sind natürlich keine repräsentativen Zahlen. Selbst bei Ubuntu mit über 2 Mio. erfassten Installationen dürfte nur einen Bruchteil in Popcon erfassen. 2015 kursierte mal die Zahl von 20 Millionen Installationen, allerdings blies man 2012 auch schon in dieses Horn.

Grundsätzlich plädiere ich bei dem ganzen Thema für mehr Zahlen. Diese müssen natürlich ethisch erhoben werden und die Einwilligung sollte bestenfalls transparent über ein Opt-in erfolgen, ansonsten wenigstens über ein prominentes Opt-out (siehe: Kommentar: Gut umgesetztes Tracking belohnen). Denn lediglich Zahlen können Linux von der unsäglichen Forkerei und den vielen Miniprojekten retten, die das Ökosystem insgesamt schwächen. Manchem Entwickler oder Maintainer sollten die geringen Nutzungszahlen einfach mal vor Augen geführt werden.


Bilder:
Einleitungs- und Beitragsbild von rawpixel via pixabay

"

14. Dezember 2019

Die PSD2 Richtlinie hat den Markt für Banking Apps dieses Jahr gehörig umgekrempelt. Ob die neue Richtlinie einen Fortschritt oder Rückschritt darstellt hängt von nationalen Betrachtungsweisen ab. Die Anpassungen zeigen aber einige Problembereiche auf - insbesondere bei freier Software.

Die PSD2 Richtlinie schlug im September diesen Jahres wie eine Bombe ein. Ähnlich wie bei der DSGVO hatten die verantwortlichen Stellen ihre Anpassungen auf den letzten Drücker umgesetzt und so ruckelte es bei vielen gehörig. Die Zwei-Faktor-Authentifizierung im E-Commerce setzten die verantwortlichen Stellen sogar ganz aus, weil die Anpassungen noch nicht weit genug fortgeschritten waren. Die meisten Bankkunden haben die neue Richtlinie in sofern abbekommen, als das sie nun andauernd eine TAN eingeben müssen. Nutzer von Banking-Apps mussten zudem Updates machen und so manche Bank sah die Gelegenheit gekommen sich von HBCI zu verabschieden (siehe auch: Onlinebanking - HBCI/FinTS einfordern).

Dabei sollte man jetzt aber nicht PSD2 pauschal verurteilen. Natürlich hat die Richtlinie ihre Schwächen und dank Lobbyarbeit profitieren vor allem neuartige FinTechs und weniger die Verbraucher. Die Richtlinie verbesserte aber die allgemeine Sicherheit schon deutlich, weil Banken nun gezwungen waren unsichere Alt-Systeme abzustellen. Ich sage nur TAN-Liste. Ich empfehle dazu immer noch Folge 157 von Lage der Nation. Wir Deutschen hatten aber mit HBCI eine sehr komfortable Ausgangslage und konnten fast nur verlieren.

Unabhängig von der politischen Bewertung illustriert die Geschichte wieder mal zwei Probleme im Linux-Sektor. Die Paketverwaltung ist Murks für Endanwenderprogramme und Open Source Programme bekommen künftig ein Problem.

Zuerst zum ersten Punkt. Die veränderten Richtlinien erforderten eine Reihe von Programmupdates bei zentralen Banking-Apps wie KMyMoney oder GnuCash, sowie zu Grunde liegenden Bibliotheken wie aqbanking. Während die meisten kommerziellen Softwareprojekte bereits im Frühjahr mit den notwendigen Aktualisierungen anfingen kamen diese Projekte erst sehr spät mit Updates daher. Allerdings schafften sie es wenigstens im September, wodurch sich die Probleme für den Endanwender in Grenzen halten würden. Es sei denn natürlich dieser Anwender setzt auf eine andere Distribution als Arch Linux - so wie rein zufällig immer noch die meisten Linux-Anwender. Während Debian wenigstens nach einigen Wochen Backports bereitstellte, stehen Ubuntu LTS Nutzer und die aller abhängigen Derivate immer noch im Regen. Dort können sie sich dann z. B. mit den Anwendern von openSUSE Leap unterhalten.

Mit Snaps oder Flatpaks wäre das nicht passiert (siehe: Snaps oder Flatpaks - Es gibt kein zurück). Dem Anwender ist es egal, ob aqbanking und KMyMoney unterschiedliche Projekte sind. Der Anwender installiert meist auch nicht KMyMoney und GnuCash zeitgleich und hat dann alles doppelt. Ich betreue ein paar PCs mit KMyMoney (weil das ein gutes Programm für Banking ist) und die Anwender haben ausreichende Linux-Kenntnisse. Ich muss dort sehr selten eingreifen, auch weil sie eingesetzten Distributionen stabil sind und daher nur alle paar Jahre umfangreiche Pflege benötigen. Aber ich kann denen kaum empfehlen selber Pakete zu bauen, Programme zu kompilieren und Konten auf der Kommandozeile einzurichten.

Unabhängig davon steht es um die Open Source Programme insgesamt nicht gut. Banken erschweren zunehmend den Zugriff via HBCI und nutzen PSD2 als Vorwand. Das ist zwar eine standardisierte Schnittstelle, aber um die nutzen zu können braucht man eine professionelle Infrastruktur, eine Zertifizierung bei der BaFin und muss jährlich erhebliche Summen in die Hand nehmen. Der Entwickler der sehr populären macOS App MoneyMoney hat auf Rückfrage mal die Kosten in Ansätzen offen gelegt. Er beabsichtigt die notwendigen Einnahmen durch ein Abonnement für diejenigen Kunden einzunehmen, die auf PSD2 für ihre Bank angewiesen sind. Doch was machen die Entwickler von Open Source Programmen? Immerhin hat Open Source immer noch kein solides Finanzierungsmodell und es fehlt auch an der notwendigen Organisationsstruktur um so etwas überhaupt anbieten zu können. Ich sehe da leider schwarz für die Zukunft. Zum Glück gibt es wenigstens in diesem Bereich auch ein paar kommerzielle Produkte für Linux.

Ich persönlich habe die ganze Entwicklung tatsächlich zum Anlass genommen mein primäres Konto zu einer Bank umzuziehen, die uneingeschränkt HBCI unterstützt. Hoffentlich noch sehr lange!


Bilder:

Einleitungs- und Beitragsbild von stevepb via pixabay

"

12. Dezember 2019

Wird die Größe einer per iSCSI oder Fibre Channel eingebundenen LUN geändert, oder in einer virtualisierten Umgebung die Größe der virtuellen Festplatte (VMDK, VDI, VHD, qcow2, etc.) angepasst, kann man den Linux-Kernel auffordern die entsprechenden Blockgeräte auf Änderungen hin zu prüfen, ohne dafür das Betriebssystem neustarten zu müssen.

Die im folgenden genannten bzw. verlinkten Kommandos wurden unter RHEL 7 mit VMDK-Dateien und iSCSI-Disks getestet. Sie sollten jedoch für Linux im Allgemeinen gelten.

Änderungen an bestehenden Blockgeräten erkennen

Um Änderungen an Blockgeräten zu erkennen, welche dem Kernel bereits bekannt sind, wird folgender Befehl mit root-Rechten ausgeführt:

# echo 1 > /sys/class/block/sdX/device/rescan

Dabei ist sdX durch die Bezeichnung des konkreten Blockgeräts wie z.B. sda oder sdb etc. zu ersetzen. Statt dem genannten Bezeichner kann auch die SCSI-Nummer des entsprechenden Gerätes verwendet werden. Der Befehl lautet dann wie folgt (wobei X:X:X:X durch die jeweilige SCSI-Nummer zu ersetzen ist):

# echo 1 > /sys/class/scsi_device/X:X:X:X/device/block/device/rescan

Update 2019-12-15: Ist das Paket parted installiert, kann man den Kernel auch mit dem Kommando partprobe über die Änderungen informieren:

# partprobe /dev/sdX

Danke an Dirk für diesen Tipp.

Neue Blockgeräte erkennen

Wie neu hinzugefügte Blockgeräte erkannt werden können, habe ich bereits im Artikel Linux: Hotplugged SATA/SAS/SCSI-Festplatten ohne Neustart erkennen beschrieben.

Quellen und weiterführende Hinweise

  1. How to rescan disk in Linux after extending vmware disk
  2. How to map Linux disk to vmware disk
  3. Red Hat Storage Administration Guide: Sec. 37.2. Resizing an iSCSI Logical Unit

Wird die Größe einer per iSCSI oder Fibre Channel eingebundenen LUN geändert, oder in einer virtualisierten Umgebung die Größe der virtuellen Festplatte (VMDK, VDI, VHD, qcow2, etc.) angepasst, kann man den Linux-Kernel auffordern die entsprechenden Blockgeräte auf Änderungen hin zu prüfen, ohne dafür das Betriebssystem neustarten zu müssen.

Die im folgenden genannten bzw. verlinkten Kommandos wurden unter RHEL 7 mit VMDK-Dateien und iSCSI-Disks getestet. Sie sollten jedoch für Linux im Allgemeinen gelten.

Änderungen an bestehenden Blockgeräten erkennen

Um Änderungen an Blockgeräten zu erkennen, welche dem Kernel bereits bekannt sind, wird folgender Befehl mit root-Rechten ausgeführt:

# echo 1 > /sys/class/block/sdX/device/rescan

Dabei ist sdX durch die Bezeichnung des konkreten Blockgeräts wie z.B. sda oder sdb etc. zu ersetzen. Statt dem genannten Bezeichner kann auch die SCSI-Nummer des entsprechenden Gerätes verwendet werden. Der Befehl lautet dann wie folgt (wobei X:X:X:X durch die jeweilige SCSI-Nummer zu ersetzen ist):

# echo 1 > /sys/class/scsi_device/X:X:X:X/device/block/device/rescan

Update 2019-12-15: Ist das Paket parted installiert, kann man den Kernel auch mit dem Kommando partprobe über die Änderungen informieren:

# partprobe /dev/sdX

Danke an Dirk für diesen Tipp.

Neue Blockgeräte erkennen

Wie neu hinzugefügte Blockgeräte erkannt werden können, habe ich bereits im Artikel Linux: Hotplugged SATA/SAS/SCSI-Festplatten ohne Neustart erkennen beschrieben.

Quellen und weiterführende Hinweise

  1. How to rescan disk in Linux after extending vmware disk
  2. How to map Linux disk to vmware disk
  3. Red Hat Storage Administration Guide: Sec. 37.2. Resizing an iSCSI Logical Unit

11. Dezember 2019

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Synology Secure Erase macht Festplatten unbenutzbar

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Seit Jahren schwöre ich auf die NAS-Systeme von Synology. Hier werkelte für gut 6 Jahre eine DiskStation DS213. Der Name verrät es schon, es handelt sich dabei um eine 2-Bay-Variante. Zum Einsatz kamen hier noch WD Red-Festplatten.

Nun haben sich meine Ansprüche sowohl, was Funktionen als auch Speicherplatz angeht deutlich verändert, weshalb ein neues System her musste. Meine Wahl fiel auf eine DS918+.

Die alte DiskStation wollte ich nun fit für Ebay Kleinanzeigen machen, dazu gehört natürlich auch die alten Festplatten zu säubern. Synology selbst bietet dafür ein entsprechendes Tool namens Secure Erase an, welches sich im DSM im Store Manager versteckt.

Nun trat während die zweite Platte überschrieben wurde jedoch ein Fehler auf. Die Synology DiskStation startete einfach neu, beim anschalten waren beide Festplatten nicht mehr ansprechbar/das ganze System bootete nicht mehr.

Meine ersten Versuche waren, die DiskStation zurückzusetzen. Dazu den Reset-Knopf auf der Rückseite vier Sekunden bis zum ersten Piep-Ton gedrückt halten und anschließend direkt wieder drücken, bis drei weitere Töne kommen. Anschließend sollte sie laut Anleitung nach wenigen Minuten unter find.synology.com wieder erreichbar sein – was auch funktionierte. Nun trat allerdings der nächste Fehler auf „Failed to format the disk 35“. Dies betraf beide Platten. Und auch direkt angeschlossen an einem PC tat sich erst einmal nichts mehr.

In der Computer Verwaltung wurden mir die Festplatten zwar immerhin angezeigt, jedoch schlug die Initialisierung fehl mit der Meldung „Datenfehler (CRC-Prüfung). Spannenderweise konnte ich die SMART-Werte sowie die Festplattengröße jedoch noch problemlos auslesen – was für mich bedeutete, dass die Festplatten an sich noch funktionieren müssten. Zudem war es merkwürdig, dass beide Festplatten exakt das gleiche identische Fehlerbild aufwiesen. Selbst eine Analyse mittels TestDisk brachte keinerlei Erkenntnis.

Die Lösung fand ich nach mehreren Tagen nun endlich im Forum von Synology.

Während des Löschvorgangs wird die Festplatte gesperrt und eine Sicherheitsstufe aktiviert. Dies wird seitens Synology nirgendwo erwähnt! Den einzigen Verweis, den ich bei meinen Recherchen dazu fand lautete wie folgt:

Wenn Secure Erase während der Ausführung unsachgemäß angehalten wird, können Sie Secure Erase direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Synology DSM Dokumentation

Da ich keine weitere Festplatte mehr hatte, habe ich kurzerhand eine virtuelle Linux-Maschine aufgesetzt, die Festplatten einzeln dran gehangen und mittels fdisk -l geprüft, welche Zuordnung diese bekommt, bei mir war dies /dev/sdb. Folgende zwei Befehle setzten die Einstellungen bzw. Festplatten dann zurück:

hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb
hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdb

sdb müsst ihr dann je nachdem wie bei euch die Festplatte eingebunden ist einmal anpassen.
Je nach Größe der Festplatte kann gerade der erste Befehl einige Minuten dauern. Nachdem ich beide Kommandos bei den Festplatten durchgeführt hatte, wurden diese endlich wieder erkannt.
Ich kann aus meiner Erfahrung somit nur von der Nutzung der Secure Erase-Funktion abraten und jedem nur ans Herz legen, diese auf keinen Fall zu verwenden. Stattdessen habe ich die Festplatten nun mittels dd gelöscht.

Photo by JC Gellidon on Unsplash

Der Beitrag Synology Secure Erase macht Festplatten unbenutzbar erschien zuerst auf timscha.io.

7. Dezember 2019

Ein kleiner Blick über den Tellerrand: im Laufe des heutigen und morgigen Tages passieren interessante Dinge bei Ethereum. Die Open Source-Software und das gleichnamige Netzwerk Ethereum bilden ein verteiltes System für DApps, die unter die Kategorie der Smart Contracts fallen. DApps kann man sich als „distributed decentraliced cloud computing“ vorstellen. Als Datenstruktur wird eine Blockchain eingesetzt. (Rudimentäre) Anwendungen (Beispielprogramm) werden dort verewigt und können über entsprechende Clients angesprochen werden.

Das Ganze basiert momentan überwiegend auf JavaScript(-ähnlichen Sprachen) und fühlt sich wie die Entwicklertools-Konsole im Webbrowser an. Aber es funktioniert und das sogar erstaunlich gut.

Ressourcen in Form von CPU-Zeit, etc. werden über den eigenen Token Ether verrechnet. Und da haben wir es: bei Ethereum stehen wir zur Hälfte in der Welt der Kryptowährungen – aber eben nur zur Hälfte.

Ethereum unterscheidet sich von Bitcoin nicht nur in den DApps sowie der Struktur. Das Netzwerk ist geprägt von ständigem Wandel, Weiterentwicklung und resultierenden Upgrades. Weit am Horizont steht der Umstieg auf "Ethereum 2.0" an. Dabei geht um die Umstellung von Proof of Work-Verfahren mit den Minern hin zum Proof of Stake-Verfahren mit sog. Validatoren. Da diese Umstellung tiefe Einschnitte in jeglicher Weise für das Netzwerk bedeutet, wird die Migration schrittweise vollzogen.

Hard Fork-Upgrade

Teil der Migration sind Upgrades, die mitunter zu einem Hard Fork führen. Dies ist immer dann der Fall, wenn die Änderungen nicht abwärtskompatibel sind, also mit dem Upgrade Abläufe und Verhaltensweisen erlaubt werden, die vorher verboten waren. Wird ein Upgrade nicht von ausreichend Nutzern adaptiert, kann sich die Blockkette teilen.

Hard Fork visualisiert

Schauen wir uns das in der Grafik einmal an und fangen oberhalb der gestrichelten Linie an, wo Version 1 läuft: Blöcke werden wie üblich der Blockchain angefügt, indem sie auf einen Parent bzw. Elternteil verweisen. Somit lässt sich rekursiv der Weg zum Urblock, dem Genesis-Block, zurückverfolgen. Das Proof of Work-Verfahren sagt weiterhin aus, dass Grundlage für neue Transaktionen die Kette an Blöcken ist („best block chain“), für die der meiste Aufwand in Form von Mining nötig war. So erklären sich auch die doppelten Blöcke mit der gleichen Nummer: sie gelten als „abgelaufen“ (stale), sofern eine andere Kette mehr Nachfolger hat. Soweit so gut – schauen wir uns nun den Bereich unterhalb der gestrichelten Linie an: hier wird Version 2 betrieben. Anfangs bei Block 99 verhält sich das System genau wie Version 1. Es ist allerdings einprogrammiert, dass ab Block 100 die Änderungen scharf gestellt werden. Das hat zur Folge, dass die dann weitergeführte Blockchain nicht mehr mit Version 1 kompatibel ist.

Problematisch ist dies, weil somit double spending, das mehrfache Ausgeben des gleichen Coins, möglich wird: wer bis zum Block 99 einen Coin in seiner Wallet hatte, kann ihn nun auf beiden Chains zwei Mal ausgeben, da die Ketten nicht mehr miteinander kommunizieren können. Werden Coins aus der Version 1-Blockchain (ab Block 100) von einer Exchange sogar noch zum Handel angeboten, ist das Chaos perfekt: dann haben wir einen weiteren Altcoin (alternative coin) mit eigenem Kurs, etc. Da alte Vermögen (die von Block ≤ 99) ebenfalls gültig sind, haben wir quasi neue Token geschaffen – der Rest ist Auslegungssache vom Finanzamt.

Um nicht durch die potentielle Fragmentierung Schaden zu erleiden, sind deshalb die Entwickler von solchen Systemen meist bemüht, eine hohe Adaption von Upgrades zu erreichen. Dazu aber später noch mehr.

Istanbul-Upgrade

Das Upgrade mit dem Codenamen Istanbul wirkt ab Blocknummer 9.069.000 und bringt für Ethereum einige Neuigkeiten mit:

  • EIP-152 soll Interoperabilität mit Zcash ermöglichen und verbessern
  • EIP-1108 und EIP-2028 machen (Privatsphäre)funktionalitäten erschwinglicher, indem die Kosten für zk-SNAKS (zero knowledge-Instrumenten für bessere Privatsphäre) angepasst und die Gebühr (bei Ethereum sog. gas) von Calldata von 68 gas pro Byte auf 16 gas pro Byte gesenkt werden
  • EIP-1884 hebt die Kosten (gas) für bestimmte opcodes an
  • EIP-1344 fügt das CHANID opcode hinzu, um die korrekte Blockkette zu tracken
  • EIP-2200 ändert das gas metering im Zusammenhang mit dem SSTORE opcode

Übrigens: die erwähnten Opcodes sind wirklich als solche zu verstehen, da Smart Contracts / DApps kompiliert werden und nur das Kompilat mit den eigenen Opcodes samt ABI in der Blockchain gespeichert und schließlich in der Ethereum Virtual Machine (EVM) ausgeführt wird.

Aber irgendwie will das Upgrade diesmal nicht so: auf ethernodes.org/istanbul lässt sich beobachten, wie viele Nodes dieses Upgrade bereits installiert haben (durch ein simples Update des Node-Clients wie geth oder parity). Momentan sind es zum Zeitpunkt des Artikels nur knapp 50 %. Gewünscht wären > 95 %.

Dabei tickt die Uhr: heute Nacht um ca. 01:00 Uhr MEZ soll Block 9069000 erreicht und das Upgrade vollzogen werden. Es bleibt zu schauen, was passiert.

Ethereum Forks sind im Gegensatz zu Bitcoin nicht unüblich: so entstand durch einen erzwungenen Hard Fork durch das Entwicklerteam in Folge des DAO-Hacks Ethereum Classic.

Wie in den letzten Jahren werde ich auch dieses Jahr wieder Threema Android Lizenzen verschenken. Dieses Jahr werde ich 5 Lizenzen verschenken. Dazu erhalten die Gewinner oder Glücklichen von mir einen Lzenzschlüssel, mit dem sie auf der Webseite von Threema dann den Android Client nach Eingabe des Lizenzschlüssel herunterladen können.

Es ist nicht möglich, damit Threema vom PlayStore sondern nur aus dem Threema Store herunterzuladen.

Teilnahme

Die Teilnahme ist ganz einfach. Die ersten 5 Nutzer die mich via XMPP / Jabber anschreiben wird (pr3ach3r@trashserver.net) und die folgenden Fragen richtig beantworten kann:

1.) Aus welchem Land kommt Threema? 2.) Was bedeuten die 3 grünen Punkte bei einem Threema Kontakt? 3.) Was ist der Threema Safe?

Ich freue mich auf eure Einsendungen. Ich möchte festhalten ich stehe in keine Zusammenhang mit Threema. Ich kaufe die Lizenzen zum vollen Preis und dieses soll auch keine Werbaktion für mich oder Threema sein. Ich will nur einen kleinen Teil zu mehr Datenschutz und Sicherheit beitragen.

6. Dezember 2019

Ein kleiner Tipp zum Nikolaus: asciinema ist ein Tool, auf das ich schon vor längerer Zeit gestoßen bin, vor allem durch die Landing Pages einiger typischer "fancy {cloud, ai, ...} tools".

In aller Kürze

Bei asciinema handelt es sich in erster Linie um ein Python-Tool, das auf dem Computer installiert wird. Soll eine Terminalsitzung dann aufgezeichnet werden, muss asciinema rec eingegeben werden. Dann wird wie in einem Screencast alles, was ein- und ausgegeben wird, in Echtzeit aufgezeichnet. Nach der Eingabe von exit oder Ctrl+D wird nun angeboten, entweder eine .cast-Datei abzuspeichern oder diese auf dem Portal asciinema.org hochzuladen. In der .cast-Datei befinden sich alle nötigen Informationen des Screencasts im – wer hätte es gedacht – ASCII-Format. Diese .cast-Datei kann nun mit entsprechender JavaScript-Lib in einem HTML5-Browser angezeigt werden. Wer das Ganze mehr hosted/SaaS-like haben möchte, kann auf den Service asciinema.org zurückgreifen.

Beispiel gefällig? Ich habe hier etwas vorbereitet.

Fazit

Aus meiner Sicht ein nettes Tool. Ich hatte es bisher nicht eingesetzt, aber im Zusammenhang mit Live Demos in Vorträgen fiel asciinema als gute Fallback-Variante ein.