WD My Cloud EX2 Ultra: OpenWrt, ein Brick und ein Flipper als Retter

Zusammenfassung

Im Oktober 2026 habe ich meiner WD My Cloud EX2 Ultra, deren Herstellerunterstützung im Dezember 2027 endet, OpenWrt aufgespielt und sie dabei zunächst in eine Bootschleife geschickt. Gerettet hat sie ein Flipper Zero als serielle Konsole, über die das Rettungssystem per YMODEM in den Arbeitsspeicher kam. Heute läuft sie als verschlüsseltes RAID1-NAS mit eigener Lüfter- und LED-Steuerung, und dieser Beitrag enthält alle Skripte und Befehle zum Nachbauen.

Warum die EX2 Ultra ein neues System braucht

Die My Cloud EX2 Ultra ist ein NAS mit zwei Plattenschächten. Innen arbeiten ein Marvell Armada 385 mit zwei Cortex-A9-Kernen bei 1,33 GHz, 1 GB Arbeitsspeicher und 256 MB NAND-Flash. Für ein Heim-NAS reicht das, auch zehn Jahre nach dem Marktstart.

Das Problem ist die Software. Laut Lebenszyklus-Richtlinie von Western Digital läuft die Unterstützung der EX2 Ultra von Februar 2016 bis Dezember 2027, und das Gerät steht schon jetzt in der Phase „Limited Updates“: Fehlerbehebungen und neue Funktionen können ausbleiben, nur kritische Sicherheitslücken werden noch geschlossen. Nach dem Ende darf WD laut derselben Richtlinie alle Updates einstellen, auch Sicherheitsupdates, und Cloud-Dienste abschalten. Was an einem Cloud-Dienst hängt, funktioniert dann nicht mehr.

Für mich heißt das: Ab 2028 hängt ein ungepatchtes System mit Samba, Weboberfläche und Fernzugriff in meinem Netz. Der Fernzugriff über die WD-Cloud fällt ohnehin weg. Ein NAS soll aber noch Jahre laufen. OpenWrt unterstützt die EX2 Ultra offiziell, bekommt regelmäßig Updates und lässt sich per sysupgrade aktualisieren. Dafür gibt es keine WD-App und keine Cloud, nur das, was man selbst einrichtet.

Mein Ziel war ein verschlüsseltes NAS mit gespiegelten Platten, das nach dem Einschalten gesperrt bleibt, bis ich mich per SSH anmelde und die Passphrase eingebe. Erst dann sollen die Freigaben per SMB erreichbar sein.

Was du mitnehmen kannst: Schau beim Hersteller nach, wie lange dein NAS noch Sicherheitsupdates bekommt. Ein Gerät ohne Updates gehört nicht ins Netz, auch nicht ins Heimnetz.

Vorher: den kompletten Flash sichern

Unter My Cloud OS 5 lässt sich SSH in der Weboberfläche einschalten. Anmelden muss man sich dann als Benutzer sshd, nicht als admin, mit dem Passwort aus der Weboberfläche. Das hat mich einen Fehlversuch gekostet.

Der Flash ist in acht Partitionen aufgeteilt: U-Boot, Kernel (uImage), uRamdisk, image.cfs, Rettungsfirmware, config und zwei Reservebereiche. Bevor irgendetwas überschrieben wird, sichere ich jede Partition mit nanddump auf einen anderen Rechner. Liest man eine Partition zweimal und vergleicht die Prüfsummen, weiß man, dass die Sicherung stimmt. Gelegentliche Meldungen über korrigierte Einzelbitfehler sind bei NAND normal.

# auf dem PC, NAS-Adresse anpassen; die WD-Firmware fragt nach dem sshd-Passwort
for i in 0 1 2 3 4 5; do
  ssh sshd@NAS-IP "nanddump -q /dev/mtd$i" > mtd$i.bin
done
sha256sum mtd*.bin > SHA256SUMS

Was du mitnehmen kannst: Eine Sicherung allein ist noch kein Rückweg. Klär vor dem ersten Schreibzugriff, wie du an das Gerät kommst, wenn es nicht mehr startet. Bei der EX2 Ultra heißt das: serielle Konsole bereithalten. Genau diesen Punkt habe ich übersprungen.

OpenWrt aufspielen

Für die EX2 Ultra gibt es im Firmware Selector von OpenWrt zwei Dateien für die Erstinstallation: squashfs-uImage-factory.bin für den Kernel und squashfs-image-cfs-factory.bin für das Dateisystem. Ich habe beide gegen die SHA256-Liste von OpenWrt geprüft und dann per SSH nach /tmp auf dem NAS kopiert. Die Anleitung aus dem ursprünglichen Pull-Request besteht aus zwei Befehlen:

flash_eraseall /dev/mtd1 && nandwrite --markbad -p /dev/mtd1 /tmp/*-uImage-factory.bin
ubiformat /dev/mtd3 -f /tmp/*-image-cfs-factory.bin -y
reboot

Danach hätte OpenWrt starten sollen. Stattdessen begann eine Bootschleife.

Der Brick: Bootschleife statt OpenWrt

Die Platten liefen an, die Power-LED blinkte, und nach wenigen Sekunden startete das Gerät neu. Ohne Platten genauso, mit gedrücktem Reset-Knopf auch. Im Netz war nichts zu sehen, keine IP-Adresse, keine Antwort.

Die Ursache zeigte erst die serielle Konsole. Der OpenWrt-Kernel startete sauber, konnte aber das UBI-Volume mit dem Dateisystem nicht einbinden:

UBI: EOF marker found, PEBs from 27 will be erased
ubi0 error: the layout volume was not found
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Rebooting in 1 seconds..

Der Fehler lag bei uns. Nach dem ubiformat hatten wir zur Kontrolle das neue UBI mit ubiattach unter dem noch laufenden WD-Kernel 4.14 eingebunden. Der hat dabei sehr wahrscheinlich die Volumes vergrößert und Verwaltungsdaten hinter den Ende-Marker des OpenWrt-Images geschrieben. Der OpenWrt-Kernel verwirft beim ersten Start alles hinter diesem Marker, und damit auch die Volumetabelle. Bewiesen ist das nicht, aber es passt zum Log.

Beim Lesen des U-Boot-Abbilds aus der Sicherung fielen zwei Dinge auf. Erstens gibt es einen Notstart über den Reset-Knopf, der /boot/uImage und /boot/uRamdisk von einem FAT-formatierten USB-Stick lädt. Zweitens sucht U-Boot dabei nach /GrandTeton/u-boot.bin und flasht sich damit selbst neu. Eine solche Datei sollte also nie auf einem Rettungsstick liegen.

Was du mitnehmen kannst: Nach dem Flashen nichts mehr „nur zur Kontrolle“ mit dem alten System anfassen. Und bei jedem unerwarteten Verhalten zuerst die Konsole lesen, statt Ursachen zu raten. Meine erste Vermutung, die alte WD-Ramdisk sei schuld, war falsch.

Rettung mit dem Flipper Zero als serielle Konsole

Auf der Platine der EX2 Ultra liegen Lötpunkte für die serielle Schnittstelle. An diese Pads habe ich Anschlüsse angelötet und drei Kabel angeschlossen: Masse, RX und TX. Die 3,3-Volt-Leitung bleibt frei. Wichtig ist der Pegel von 3,3 V: Ein klassischer USB-Seriell-Adapter mit 9-poligem Stecker arbeitet mit RS-232-Pegeln um ±12 V und kann den Prozessor beschädigen.

Als Adapter diente ein Flipper Zero mit der Firmware Unleashed. Seine App GPIO → USB-UART Bridge macht ihn zu einem USB-Seriell-Adapter mit 3,3-V-Pegel. Pin 13 ist TX, Pin 14 RX, Masse liegt auf Pin 8, 11 oder 18. Die Leitungen werden über Kreuz verbunden: TX des Flippers an RX des NAS und umgekehrt. Am Rechner erscheint der Flipper dann als /dev/ttyACM0, eingestellt werden 115200 Baud, 8N1.

Die nächste Hürde: U-Boot hält nicht bei jeder Taste an. Nur die Taste 1 unterbricht den Countdown von einer Sekunde, danach erscheint die Eingabeaufforderung Marvell>>. Mein Skript schickt deshalb ab der ersten U-Boot-Zeile ununterbrochen Einsen.

TFTP schied aus. Der Netzwerkport hängt an egiga2, und U-Boot meldete beim Aktivieren nur mvNetaPortEnable failed. Also kam das OpenWrt-Rettungssystem (initramfs-kernel.bin, 6,6 MB) über die serielle Leitung: U-Boot nimmt mit loady Dateien per YMODEM entgegen. Bei 115200 Baud dauerte das gut zehn Minuten, im Video steigt der TX-Zähler des Flippers.

Marvell>> loady 0x2000000        # YMODEM-Upload starten, dann ymodem_send.py am PC
Marvell>> iminfo 0x2000000       # Prüfsumme des geladenen Images kontrollieren
Marvell>> bootm 0x2000000        # OpenWrt aus dem RAM starten

# im laufenden Rettungssystem (nichts davon wird gespeichert):
/etc/init.d/dnsmasq stop                       # kein fremder DHCP-Server im LAN
ip addr add FREIE-IP/24 dev br-lan
cd /tmp && wget http://PC-IP:8080/sysupgrade.bin
sha256sum sysupgrade.bin                       # gegen die OpenWrt-Liste prüfen
sysupgrade -T sysupgrade.bin && sysupgrade -n sysupgrade.bin

Das offizielle sysupgrade.bin formatiert das UBI dabei sauber neu. Danach startete OpenWrt 25.12.5 aus dem Flash, und zwar dauerhaft. U-Boot selbst habe ich nie angefasst und auch keine Umgebungsvariable gespeichert.

Was du mitnehmen kannst: Wenn kein Netz geht, geht fast immer noch die serielle Leitung. Langsam, aber zuverlässig. Und ein Flipper Zero ist ein brauchbarer UART-Adapter, wenn gerade kein anderer da ist.

Lüfterumbau: Noctua statt Sunon

Ab Werk sitzt ein Sunon-Lüfter mit 40 mm im Rahmen. Ich habe ihn gegen einen Noctua NF-A4x10 FLX (Affiliate-Link: Bei einem Kauf erhalte ich eine kleine Provision, der Preis ändert sich für dich nicht) getauscht, der deutlich leiser läuft. Der Noctua ist ein bis zwei Millimeter zu groß für den Halter. Mit einer Feile oder einem Cuttermesser ist das schnell angepasst, das Kunststoffgehäuse lässt sich gut bearbeiten.

Der Lüfter hängt nicht an Linux, sondern an einem Mikrocontroller auf der Platine. Ohne Befehle läuft er auf Vollgas. Das ist sicher, aber laut. Wie man ihn regelt, steht im nächsten Abschnitt.

Der Mikrocontroller: Lüfter, Power-LED und Temperatur

Die WD-Firmware spricht mit dem Mikrocontroller über /dev/ttyS1 mit 19200 Baud. Jedes Paket hat sieben Bytes und beginnt mit FA und endet mit FB. Die Befehle stammen aus zwei Projekten, die das Protokoll ausgelesen haben: mcm-daemon und mcm-fancontrol. Auf der EX2 Ultra habe ich jeden Befehl einzeln getestet.

• FA 03 01 00 00 00 FB: Gerät bereit. Danach hört die Power-LED auf zu blinken.
• FA 03 08 00 00 00 FB: Gehäusetemperatur lesen. Der Rohwert wird über eine Tabelle in Grad umgerechnet.
• FA 02 01 00 00 00 FB: Drehzahl lesen. Umdrehungen pro Minute = 300000 / Rohwert.
• FA 02 00 XX 00 00 FB: Lüfterstufe setzen, XX von 00 (aus) bis D2 (Vollgas).
• FA 26 00 XX 00 01 FB: Power-LED. XX = 11 blau, 41 blau pulsierend, 24 rot blinkend, 22 orange blinkend, 01 aus.

Mit dem Noctua habe ich alle Stufen durchgemessen. Stufe 9 bringt rund 4480 Umdrehungen pro Minute, Stufe 8 rund 4100, Stufe 7 rund 3500, Stufe 6 rund 2750, Stufe 5 rund 2030 und Stufe 4 rund 1630. Bei Stufe 1 und 2 steht der Noctua. Stufe 3 hält ihn zwar bei rund 1200 Umdrehungen, aber nur, wenn er von oben kommt. Zweimal blieb er beim Herunterregeln auf Stufe 3 stehen. Deshalb ist Stufe 4 meine niedrigste Laufstufe, und aus dem Stand bekommt der Lüfter immer drei Sekunden Stufe 9 als Anlaufhilfe.

Daraus ist der Dienst wd-mcu entstanden, ein Shell-Skript mit procd-Init. Er liest alle 30 Sekunden alle verfügbaren Temperaturen: Gehäuse über den Mikrocontroller, CPU, Netzwerk-PHY und beide Platten über den Kerneltreiber drivetemp. Schlafende Platten fragt er nicht ab, damit er sie nicht weckt. Jeder Sensor hat eine Aus-, eine Ein- und eine Vollgasschwelle, zum Beispiel die Platten 38, 40 und 50 °C und die CPU 65, 70 und 75 °C. Liegen alle Sensoren unter ihrer Ausschaltschwelle, steht der Lüfter still.

• Power-LED blau: alles in Ordnung.
• Power-LED blau pulsierend: beide Platten schlafen.
• Power-LED rot blinkend: Der Lüfter meldet auch nach der Anlaufhilfe keine Drehzahl.
• Power-LED orange blinkend: Der Dienst läuft nicht, der Lüfter steht auf Vollgas.
• Platten-LED violett blinkend: Platte vorhanden, NAS noch gesperrt. Platten-LED blau: entsperrt, flackert bei Zugriff. Platten-LED rot: mdadm hat die Platte als defekt markiert.

Die Platten-LEDs hängen direkt an GPIO-Pins und kennen nur an und aus, weich pulsieren können sie nicht. Violett entsteht aus Rot und Blau zugleich. Mit den Blink-Timern des Kernels liefen beide Farben gegenphasig, das Ergebnis war ein Wechsel von Rot und Blau. Deshalb schaltet ein kleiner Hintergrundprozess beide Farben im selben Moment. Für stty braucht die Minimal-Busybox von OpenWrt das Paket coreutils-stty.

Was du mitnehmen kannst: Miss die Lüfterstufen mit deinem Lüfter, statt Werte zu übernehmen. Gerade leise Lüfter laufen auf den untersten Stufen nicht zuverlässig an.

Plattentests: Wenn 385 MB/s gelogen sind

Zuerst steckten zwei WD Red WD40EFAX mit 4 TB im Gerät. Ein reiner Lesetest lieferte 385 MB/s, über die ganze Platte gleich schnell. Das konnte nicht stimmen, die Platte schafft laut Datenblatt rund 180 MB/s. Die WD40EFAX ist eine SMR-Platte, und Bereiche, die nie beschrieben wurden, liefert ihre Firmware offenbar direkt als Nullen aus, ohne die Magnetscheibe zu lesen. Gemessen hatte ich also nur die SATA-Anbindung. Erst nach einem Schreibtest kamen ehrliche Werte: rund 190 MB/s außen, 151 MB/s in der Mitte und 77 MB/s innen.

Danach habe ich auf zwei 8-TB-Platten gewechselt, eine WD Red Plus WD80EFPX und eine Seagate SkyHawk ST8000VX0022, beide mit herkömmlicher CMR-Aufzeichnung. Gemessen wurde roh und sequentiell mit dd, jeweils 4 GiB am Anfang, in der Mitte und am Ende der Platte, dazu 20 GiB Dauerschreiben:

• WD80EFPX lesen: 233, 184 und 99 MB/s. Schreiben: 225, 180 und 97 MB/s. Dauerschreiben: 210 bis 216 MB/s.
• ST8000VX0022 lesen: 238, 204 und 117 MB/s. Schreiben: 187, 199 und 116 MB/s. Dauerschreiben: 222 bis 226 MB/s.
• Beide gleichzeitig: 469 MB/s lesen, 297 MB/s schreiben. Beim parallelen Schreiben bremst der Prozessor.

Vor dem Test habe ich mit smartctl die SMART-Werte gelesen. Die WD80EFPX hatte 182 CRC-Fehler im Zähler, also Übertragungsfehler aus ihrem früheren Einsatz. Während aller Tests im NAS stieg der Zähler nicht. Die Seagate hat über 66.000 Betriebsstunden und meldet, dass sie früher einmal zu heiß war. Für Daten, die mir wichtig sind, vertraue ich ihr nur im Spiegel.

Was du mitnehmen kannst: Ein Lesetest auf einer leeren Platte sagt bei SMR-Platten nichts. Erst schreiben, dann lesen.

Verschlüsselung: der Benchmark, der in die Irre führt

Der Armada 385 hat eine eigene Krypto-Einheit, CESA genannt. cryptsetup benchmark zeigte damit für AES-CBC rund 94 MiB/s, für AES-XTS in Software nur 47 bis 54 MiB/s. Ich habe mich deshalb zuerst für CBC mit ESSIV entschieden und btrfs RAID1 über zwei verschlüsselte Platten gelegt. Die erste große Kopie kam dann auf weniger als 20 MB/s.

Die Analyse zeigte zwei Ursachen. Erstens nutzt dm-crypt die CESA gar nicht. /proc/crypto zeigt für das Laufwerk essiv(cbc-aes-neonbs,sha256-neon), also die NEON-Software, und der Interrupt-Zähler der CESA stand still. Der Benchmark misst über eine andere Kernelschnittstelle und bekam die Hardware, dm-crypt bekommt sie nicht. Zweitens verschlüsselt btrfs RAID1 über zwei LUKS-Geräte jeden Block zweimal, einmal pro Platte.

Ein Test mit dm-crypt auf einer RAM-Disk, also ohne Plattenbremse, bestätigte das:

• AES-CBC-ESSIV mit 128 Bit, einmal verschlüsselt: 42 MiB/s schreiben, 59 MiB/s lesen.
• AES-XTS mit 128 Bit, einmal verschlüsselt: 54 MiB/s schreiben, 57 MiB/s lesen.
• AES-CBC-ESSIV, zweimal verschlüsselt wie bei btrfs RAID1 über zwei LUKS: 22 MiB/s schreiben.
• AES-XTS, zweimal verschlüsselt: 27 MiB/s schreiben.

XTS ist in Software beim Schreiben also schneller als CBC und zugleich das sicherere Verfahren. Die größte Wirkung hat aber, nur einmal zu verschlüsseln. Das endgültige Konstrukt ist deshalb: beide Platten als mdadm RAID1, darüber ein einziges LUKS2 mit aes-xts-plain64 und 256-Bit-Schlüssel, also AES-128, darüber btrfs mit doppelt gespeicherten Metadaten. btrfs erkennt damit weiterhin beschädigte Dateien über seine Prüfsummen, kann Datenfehler aber nicht mehr selbst aus der zweiten Kopie reparieren. Lesefehler einer Platte fängt mdadm ab.

ZFS mit eigener Verschlüsselung hätte beides vereint, eine Verschlüsselung und Selbstheilung. Für die EX2 Ultra gibt es aber kein ZFS-Paket in OpenWrt, und auf einem 32-Bit-ARM mit 1 GB Arbeitsspeicher raten die Entwickler davon ab.

Was du mitnehmen kannst: Miss Verschlüsselung mit dem Werkzeug, das du später wirklich benutzt. cryptsetup benchmark und dm-crypt können auf derselben Hardware sehr unterschiedliche Implementierungen verwenden.

mdadm und ein zweiter Absturz

Die Installation des Pakets mdadm ließ das NAS zweimal hintereinander neu starten. Die Kernelmodule md-mod und raid1 ließen sich einzeln problemlos laden, und apk add --no-scripts mdadm lief ebenfalls sauber durch. Mein Verdacht, den ich bewusst nicht nachgestellt habe: Das Installationsskript startet den Dienst sofort, und der durchsucht mit mdadm --assemble --scan alle Blockgeräte, auch die rohen NAND-Partitionen mit U-Boot. Seit mdadm nur noch die SATA-Platten durchsuchen darf, läuft alles stabil:

apk add --no-scripts mdadm
cat > /etc/config/mdadm <<'EOF'
config mdadm
	list devices "/dev/sd*"
EOF
/etc/init.d/mdadm enable && /etc/init.d/mdadm start

Eine zweite Lehre aus diesem Absturz: Die halb installierten Dateien waren 0 Byte groß. Löscht man solche Reste direkt in /overlay/upper, während das Overlay eingehängt ist, meldet das System Stale file handle. Aufräumen also immer über die normalen Pfade oder nach einem Neustart.

Das fertige NAS

Nach jedem Start ist das NAS gesperrt. Die Platten-LEDs blinken violett, SMB ist aus. Melde ich mich per SSH an, fragt ein Skript in /etc/profile.d, ob ich entsperren will. Nach der Passphrase prüft nas-entsperren den Zustand des RAIDs, öffnet LUKS, hängt btrfs ein und startet erst dann den SMB-Server ksmbd. Fehlt eine Platte, fragt es vorher nach. nas-sperren macht alles in umgekehrter Reihenfolge.

Für SMB habe ich ksmbd statt Samba genommen, weil es im Kernel läuft und weniger Rechenleistung braucht. Jeder Benutzer bekommt ein Linux-Konto ohne Anmeldemöglichkeit, eine private Freigabe mit seinem Namen und Zugriff auf die gemeinsame Freigabe gemeinsam. Dort sorgt das setgid-Bit dafür, dass neue Dateien der Gruppe gehören. nas-benutzer legt Benutzer an, ändert Passwörter und löscht sie wieder. Beim Löschen werden die Daten nicht entfernt, sondern in ein Archiv verschoben.

Die Platten legt hd-idle nach 120 Minuten ohne Zugriff schlafen. Kürzere Zeiten bedeuten mehr Anlaufzyklen und damit mehr Verschleiß. Die erste Synchronisation des RAIDs mit 8 TB lief mit rund 206 MB/s, mdadm schätzte dafür gut zehn Stunden. Wie schnell SMB mit dem neuen Aufbau im Alltag ist, habe ich noch nicht gemessen. Nach dem RAM-Test erwarte ich beim Schreiben um die 50 MB/s statt der 20 MB/s des ersten Versuchs.

ssh root@NAS-IP
NAS ist gesperrt (SMB aus).
Jetzt entsperren? [J/n]
Passphrase für das NAS:
NAS entsperrt: 7.3T gesamt, 7.3T frei, RAID [UU]; SMB aktiv (gemeinsam und je Benutzer).

Nachbauen: alle Skripte

Alle Skripte laufen auf OpenWrt 25.12.5 mit der Busybox-Shell. Ich habe sie so veröffentlicht, wie sie auf meinem NAS laufen. nas-einrichten löscht beide Platten vollständig, das Skript fragt dafür ausdrücklich nach.

• openwrt-konfig.txt: Paketliste, mdadm-Einschränkung auf /dev/sd* und hd-idle-Konfiguration
• wd-mcu.sh: Lüfter- und LED-Dienst, nach /usr/sbin/wd-mcu
• wd-mcu.init: procd-Init dazu, nach /etc/init.d/wd-mcu
• nas-gemeinsam.sh: gemeinsame Funktionen, nach /usr/lib/nas-gemeinsam.sh
• nas-einrichten.sh: einmalige Einrichtung: GPT, mdadm RAID1, LUKS2 XTS, btrfs, Freigaben
• nas-entsperren.sh: Entsperren, Einhängen, SMB starten
• nas-sperren.sh: SMB stoppen, Aushängen, LUKS schließen
• nas-benutzer.sh: Benutzer anlegen, Passwort ändern, löschen, auflisten
• nas-profile.sh: Abfrage beim SSH-Login, nach /etc/profile.d/nas.sh
• ymodem_send.py: YMODEM-Sender für den Upload an U-Boot über die serielle Leitung
• serial_expect.py: einfaches Expect für die serielle Konsole, schickt auch die Taste 1 an U-Boot
• serial_read.py: liest die serielle Konsole mit

Die Reihenfolge, wenn du es nachbauen willst: Flash sichern, serielle Konsole anschließen und testen, OpenWrt flashen und danach nichts mehr mit dem WD-System einbinden, Pakete installieren, mdadm einschränken, wd-mcu einrichten und die Lüfterstufen selbst messen, dann nas-einrichten. Die Pfade der eigenen Skripte gehören in /etc/sysupgrade.conf, damit sie ein Update überstehen.

Zahlen im Überblick

• Western Digital gibt für die My Cloud EX2 Ultra Unterstützung von Februar 2016 bis Dezember 2027 an; danach können auch Sicherheitsupdates entfallen.
• Die YMODEM-Übertragung des 6.657.783 Byte großen Rettungssystems über 115200 Baud dauerte 611 Sekunden.
• dm-crypt mit AES-XTS-128 schrieb auf dem Armada 385 im RAM-Test 54 MiB/s bei einfacher und 27 MiB/s bei doppelter Verschlüsselung.
• Der Noctua NF-A4x10 FLX erreichte an der Lüftersteuerung der EX2 Ultra höchstens rund 4480 Umdrehungen pro Minute und blieb unterhalb von Stufe 3 stehen.

Referenzen

• Western Digital: Product Lifecycle Support Policy
• Diskussion auf Reddit: Heads up, WD My Cloud NAS (most devices) losing …
• OpenWrt Firmware Selector: WD My Cloud EX2 Ultra
• OpenWrt Pull-Request #2040: Unterstützung für die EX2 Ultra
• mcm-daemon: Protokoll des Mikrocontrollers
• mcm-fancontrol von Nico Maas
• Nico Maas: WD My Cloud Mirror Gen2 mit Debian 11

Bemerkungen

• Die Arbeiten an Software und Konfiguration hat mein SoftwareSklave ausgeführt, Löten, Lüftertausch und Entscheidungen lagen bei mir. Der Brick geht auf sein Konto, die Rettung auch.
• Mit leisem Lüfter wird es in der EX2 Ultra warm: Im Leerlauf lag das Gehäuse um 49 °C und die Seagate-Platte um 46 °C, der Lüfter regelte entsprechend hoch.

OpenWrt für die EX2 Ultra ansehen →

Links zur Originalquelle und zum Webarchiv öffnen einen neuen Tab.