marcoj1984

So Problem gebannt. Der Arbeitsspeicher war es nicht, der Test lief Problemlos durch. Bei mir lag es an dem onboard SATA III Marvell Controller. Ich hatte ohnehin das Problem, dass sobald ich 2 HDDs an dem hatte, im unRAID keine mehr auftauchte obwohl sie von Controller gelistet wurden. Hier im Forum hatte ich gelesen das es wohl ein Bug sei mit Marvel Controllern und Virtualisierung und man hier mit iommu=pt das ganze "umgehen" könnte. Dies hat soweit auch wunderbar geklappt. Entweder hat der Controller einen an der Klatsche oder es ist nicht sinnvoll iommu=pt zu setzen. Zumal soweit ich das gesehen habe dies für AMD Systeme ist und nicht für Intel. Ich habe es jedenfalls erstmal so gelöst, dass ich einen anderen SATA II Controller vom Board anstelle des SATA III Marvels genommen habe. Für die Datenplatten ist SATA II ausreichend. Und siehe da, es läuft und es gibt keine Lesefehler mehr. Von meiner Seite sehe ich mein Problem damit als erledigt an. Hatte also nichts mit dem Update zu tun. War nur ein ungünstiger Zeitpunkt bei mir. An dem alles aufeinander traf. Bleibt nur noch die Frage was aus MCP561 seinem Problem geworden ist.

Ok nun bin ich total verwirrt. Ich befürchte ich sollte nochmal von vorn anfangen mit dem Array. Aber zuvor muss ich irgendwie den Arbeitsspeicher testen um sicher zu gehen. Nachdem er die 10 TB datenplatte deaktiviert hatte habe ich eine Prüfung angestoßen, welche soweit auch erfolgreich durchlief. Jetzt habe ich mir "den Spass" erlaubt die 10 TB Platte zu entfernen und wieder hinzuzufügen. Daraufhin läuft nun ein Paritäts-Sync/Datenwiederherstellungs Prozess. Dieser lief für gut 1,5h Stunden, als dann plötzlich Lesefehler auftraten. Interessanterweise traten diese nicht wie beim Ursprung auf Disk 1 auf sondern direkt gleich bei Disk 0 und 2. Und wenn man sich die Menge anschaut ist es auch extrem. Da gestern nichts gefunden wurde und das System mit dem Array aktuell so ankommt, denke ich, dass ich um einen Neustart des Arrays nicht herum kommen werde. Aber zuvor würde ich gern den Arbeitsspeicher Testen. So wie die Lesefehler zwischen den Platten umherspringen gehe ich stark davon aus, dass wenn es ein Hardwarefehler ist, dieser dort zu finden sein dürfte. Irgendwelche Ideen für eine zuverlässige RAM Prüfung?

Ich hab grad nochmal geschaut. Auch die 2 Mails die versendet wurden waren jetzt nicht sehr aufschlussreich: Event: Unraid Disk 1 error Subject: Alert [TOWER] - Disk 1 in error state (disk dsbl) Description: ST10000VN0008-2PJ103_ZS503EBB (sdd) Importance: alert Event: Unraid array errors Subject: Warning [TOWER] - array has errors Description: Array has 1 disk with read errors Importance: warning Disk 1 - ST10000VN0008-2PJ103_ZS503EBB (sdd) (errors 2) Vielleicht sollte man hier auch etwas mehr preisgeben wenn schon per Default die logs beim Neustart verschwinden. Es hätte ja auch was mit der Stromversorgung sein können was es ausgelöst hat. Da fällt mir direkt auf steht doch read errors drin

Ich bin davon ausgegangen das ich nach einem Reboot noch hinein schauen kann. Wie lässt man es denn richtig loggen? Logserver bringt da ja auch nichts, wenn er auf der selben Umgebung läuft. Ich hätte hier gedacht, das er wenigstens beim Booten logt warum er die Platte zwar mountet aber nicht im Array aktiviert. Deswegen nur etwas blass... wäre halt mit Arbeit verbunden. Also könnte man davon ausgehen, dass er die Platte ausgehängt hat weil er einen Fehler gefunden hat. Da alle Docker + VMs im Cache laufen und ich eigentlich nur Dokumente/Bilder/Musik/Filme auf der Datenplatte habe, dass ich bis auf die Filme meine Daten lösche, das Array neu aufsetze und die Daten aus der Cloud neu ziehen lasse. Wenn irgendwann mal ein Film herumspinnt, kann ich ihn ja immer noch von der BD neu kopieren. Aber kann ich das Array neu aufsetzen mit einer bestehenden Datenplatte? Sonnst müsste ich ja nochmal 7TB durch das Netz schieben, Parität aufbauen etc.

Interessant, genau das ist mir über Nacht auch passiert. Ich habe, nachdem ich jetzt mit meinen Daten soweit von meiner alten NAS umgezogen bin die erste Platte der NAS in das Unraid reingehängt um noch etwas Puffer zu haben. Der Vorgang dauerte natürlich auch mit einer 3TB Platte etwas. Heut morgen war dann die 10 TB Datenplatte deaktiviert. Es standen 2 Fehler dran, welche ich jedoch nicht ausfindig machen konnte. Ich habe daraufhin unRAID rebootet, dies hat jedoch auch nur den Error Counter auf 0 zurück gesetzt. Auch während des Bootvorgangs gibt er im Log nicht an, warum er sie herausgenommen hat geschweige denn sie nicht wieder aufnimmt. Ich bin nur froh, das ich kurz zuvor schon die Parität hergestellt habe sonst wäre ich jetzt schon etwas bleich um die Nase rum, nachdem ich die Platten aus der alten NAS genommen habe. Durch den Neustart sind jetzt natürlich auch bei mir die 2 Fehler weg.

Du hast recht, mit dem Inkognito Modus kann ich mich in der Tat wieder anmelden. Auf die Idee wäre ich jetzt nicht gekommen denn Cookies hatte ich schon unter Verdacht. Aber da hatte selbst das Löschen nichts gebracht und bringt auch jetzt nichts aber im Inkognito geht es In den Logs werden auch die "Fehlversuche" der Logins als erfolgreich geloggt .

Hallo, Ich eiere Jetzt schon eine Weile herum mit dem folgenden Problem. Jedes mal, sobald ich das root Kennwort über das Web Frontend ändere, werde ich von unRAID ausgesperrt. Erst dachte ich es handle sich um einen Bug, und habe mal die 6.9.x RC2 versucht. Hier war leider nicht anders. Bei allem was ich recherchieren konnte, war grundsätzlich die Rede von Sonderzeichen welche wohl im Web Frontend nicht richtig escaped wurden. Leider hatte das von mir gesetzte nur [A-Z][a-z][0-9] und 8 Zeichen Länge. Also habe ich erstmal mit unRAID ohne root Kennwort weitergemacht, meine VMs und Docker Container eingerichtet etc. Jetzt nach dem Update auf 6.9.1 dachte ich mir, ich versuche es nochmal aber nichts ist. Ich habe jetzt zu guter Letzt "1234" als Kennwort versucht, mit dem selben Effekt. Was mir allerdings bei einer meiner vorhin gemachten (ca. 5) Versuche aufgefallen ist: Nach einer der Änderungen konnte ich mich mit dem neuen Kennwort einlogen. Ein paar Klicks später (< 5 Sekunden) wurde ich erneut auf die Loginseite zurückgeworfen und konnte mich nicht wieder anmelden. Um wieder Zugriff zu erlangen, musste ich bisher die üblichen 3 Verdächtigen (passwd, shadow, smbpasswd) löschen. Vielleicht hat ja jemand eine Idee, ich kann mir nicht vorstellen, dass ich der einzige damit bin. Zumal ich grad am Anfang das ganze auf frisch aufgesetzten Systemen versucht habe. Auch mögliche defekte Hardware (wie auch immer dies aussehen könnte), können ausgeschlossen werden. Das System Werkelt nun final auf der 3. Hardware, nachdem mir die Anderen zu schwach auf der Brust waren bzw. kein VT-D konnten.