Also bei mir passen die Angaben im "Ressourcemonitor" mit denen von ps.
Beide sagen, dass es auf dem kleinen TS-233 aktuell 5885 Zombies sind. Und wie gehabt, alles nur md5sum, curl und grep. Das Pyhton-Script ist leider pyc und daher nicht "human readable", mich hätte ja mal interessiert, was die da treiben. Vermutlich per curl eine Datei holen, dann mit md5sum und grep was prüfen.
Huch, doch... manche Teile vom Control Panel sowie Storage und Snapshots funktionieren nicht mehr.
Ah, okay... also doch negative Auswirkungen. Aber schon interessant, dass es sich allgemein im "Control Panel" und dem "Storage und Snapshots" auswirkt.
Beim den Begriffen im Pfad hätte ich eher auch härtere Auswirkungen in Richtung des Netzes getippt, also eine eventuelle Nichterreichbarkeit des NAS, usw.
UdoA Okay, also noch jemand bei dem des der gleiche Phyton-Prozess ist.
Halten wir also mal fest, dass das Zombie-Problem vermutlich zu großen Teilen bei fast allen betroffenen von diesem Prozess stammt. Dann hat QNAP da scheinbar ein ziemlich blödes Problem und das auch schon seit ein paar QTS-Versionen; denn neu ist das Phänomen nicht.
Ist eventuell der Hampelmann Roboter (Qboost) ein Zombiekiller und beendet die Prozesse? Ich hab den nirgendwo installiert und kann es nicht testen...
Qboost habe ich auch nicht installiert. Aber einen Zombie kann man in den meisten Fällen nicht "killen", da hilft es meistens nur den Vater-Prozess zu "töten".
Allerdings bin ich mir nicht sicher, ob ich das Experiment wagen will und den python /usr/local/network/nmd/nmd.pyc abschieße.
UdoA Ist das bei Dir auch der Vater-Prozess von (fast) allen Zombies?
Also gehen wir mal davon aus, dass es ein Problem in /usr/local/network/nmd/nmd.pyc ist.
Zumindest habe wir nun von drei Usern mit verschiedenen NAS-Modelle und verschiedenen QTS-Versionen den gleichen Verursacher.
tiermutter Mavalok2 Und nun? Sollen wir zum Spaß jeder ein Ticket aufmachen und uns beschweren, dass /usr/local/network/nmd/nmd.pyc unsere Systeme mit Zombies von md5sum, grep und curl flutet?
Mavalok2 Ich denke nicht, dass es vom QTS selbst kommt...
Ich habe da eher eine AppCenter App in Verdacht. Auf Grund des Pfads zu Python "/network/nmd/" tippe ich auf den Netzwerk-Manager "Netzwerk- und virtueller Switch 2.4.0" -- aber das nur ein Verdacht.
Ich habe das Zombie-Phänomen sowohl auf ARM-Architektur als auch auf Intel-Architektur, bei einem QTS 5.0.1.2194 und einen QTS hero 5.0.1.2192!
Stammen die Zombies bei Dir auch von einem Python aus dem Pfad? Mavalok2
tiermutter Und wer ist Vater-Prozess der md5sum? Auch wie bei mir das python nmd.pyc?
Geht doch noch... mein TS-233 hat ca. 5300 Zombies zur Zeit und mein TS-h886 hat 498 Zombies.
Alle Zombies sind curl, grep und md5sum.
Auch stammen alle Zombies vom gleichen Parent-Prozess ab, das ist auf beiden NAS (TS-233 und TS-h886) der Python-Prozess "python /usr/local/network/nmd/nmd.pyc".
Genau so, wie QNAP den LVM modifiziert, haben sie auch die Volume-Verschlüsselung angepasst.
Und selbst auf einem Multi Core XEON wird sequentiell ein Volume nach dem anderen entschlüsst.
Das heißt alle anderen Volumes müssen warten und so summieren sich die Minuten...
Rein aus dem QuLog braucht er gute 5 Minuten, aber das ist nur die reine technische Reboot-Zeit zwischen letzten Log-Eintrag vor und ersten Log-Eintrag nach dem Reboot.
Bis das letzte Volume "entschlüsselt" ist und alle AppCenter Apps wieder laufen dauert es dann noch eine Weile.
Als "Faustregel" kann ich sagen, dass ein Reboot-Vorgang ca. eine Stunde bei mir braucht... also aus dem Zustand "funktionales NAS" zurück in den Zustand "funktionales NAS".
Nein, einbauen kannst Du alles direkt am Anfang. Du musst nur als erstes die SSDs einrichten.
Weil die ersten konfigurierten Datenträger werden als SYSTEM verwendet. Wobei SYSTEM nicht für BETRIEBsystem steht,
das wir als RAID-1 über ALLE Datenträger gespiegelt.
Faust-Regel: Das SYSTEM-Volume ist das ERSTE eingerichtete Volume: da nimmst Du dann SSDs.
Liest eigentlich auch jemand meine eigentliche Frage?
Na, klar... die ursprüngliche Frage war:
Kann man mich auf die Sprünge helfen?
Und die Antwort ist: Bei einer 12 Monate alten Platte, nicht nachdenken... RMA machen und neue Platte bekommen. Viel mehr auf die Sprünge helfen kann man Dir nicht. 
Wenn die Platte noch keine 12 Monate alt ist, würde ich nicht lange fackeln und einen RMA-Austausch beim Hersteller machen.
Die Fehlermeldungen sind immer Aktionen mit dem Internet, also HDD-Daten hochladen, APPs auf Updates prüfen, usw.. Es sieht also so aus, dass das NAS seit dem 1.12. nicht mehr "ins Internet" darf.
Die Sicherungs-Jobs laufen im lokalen Netz, daher funktionieren sie. Das Versenden der Mail ist dann wieder Verkehr ins Internet, der nicht zu funktionieren scheint.
Ich habe da eine kleine TS-233, bei der ist das Release bisher nicht angekommen.
Die sagt bei der Prüfung immer, dass sie noch aktuell sei.
Ich finde die Lösung überall gültige Zertifikate zu installieren aber gar nicht so schlecht. Zumindest wenn man auch weiterhin seine eigenen ROOT-CA hinterlegen kann/darf.
Resolved an issue where QTS login screen still displayed the "Version" string even though firmware version information was no longer available since a previous QTS update.
Das sie das mal gefixt haben, das wundert mich schon fast. 
Anthracite Und da bin ich halt anderer Meinung. Mein Heimnetz ist mir wichtiger als das Firmennetz. Entsprechend ist mein Heimnetz auch deutlich mehr abgesichert bzw. abgeschottet als viele (mir bekannte) Firmennetze.
Gibt es in deinem Haushalt destruktive Elemente, die unerwünschten Zugriff auf Freigaben erlangen könnten (und seien es nur Gäste)?
Da ist ein altmodischer Gedanke, sich auf einen "Perimeter" zurückzuziehen. Frei nach dem Motto "mein Heimnetz ist sicher". Falsch!
Aus Sicht der IT Security gilt heute einzig zero trust als zeitgemäß. Aus jedem Betrachtungswinkel eines IT-Systems muss von einer Kompromitierung der Umgebung ausgegangen werden.
Daher ist auch das Heimnetz grundsätzlich nicht vertrauenswürdig. Es ist zwar nicht so gefährlich, wie das "böse" Internet oder ein Hotel-WLAN. Aber man kann es nicht als "safe haven" definieren.
Folglich müssen alle Systeme, damit auch das NAS auf eine maximale Reduktion der Angrifsvektoren ausgelegt sein.
Da macht das DHCP nichts, weil zum Zeitpunkt als die IP per DHCP vergeben wurde war sie frei. Die Erkennung von statischen IPs funktioniert nur, wenn diese auch "in Nutzung" sind. Das ist in der Tat die einzige Schwachstelle, wo es zu einem IP-Konflikt kommen kann.
Wissen wie das eigene Netz funktioniert -- unbezahlbar.
Sorry, das erinnerte mich irgendwie an die Werbung einer CC.
