Ford Prefect

wie gesagt, das ist nur die Kopfschmerztablette um die Meldung im LOG loszuwerden. Interessanter wäre, welcher andere, von Dir installierte Service (Docker, Plugin) sich den Port zuerst "krallt" und dem unraid-Host zuvorkommt. Mich würde es nicht ruhig schlafen lassen, wenn man nicht weiss WAS dieser Service auf dem Port macht/warum es ihn gibt...kann ja auch ein China-Trojaner sein

Du bist schon lustig...ist ein angelsächsisches Produkt, die Entwickler sitzen in USA...ich nutze prinzipiell keine Software in dt. Einstellungen....auch die "Grossen" kriegen das nicht hin. Internationalität ist gut, aber hat manchmal seine Grenzen. Ausserdem nutze ich unraid schon seit v3...da gab es GUI-Übersetzungen noch nicht. Nein, das meinte ich nicht. Schau mal hier: https://github.com/unraid/lang-de_DE und dann in https://github.com/unraid/lang-de_DE/blob/master/settings.txt steht in Zeile 406 (alphabetisch, nach EN-Benamsung sortiert): 406 Management Access=Verwaltungszugriff Ist ja egal ob Du es aktiv nutzt...der Service scheint aktiviert zu sein und ein weiterer Prozess kommt dem internen unraid Service zuvor und blockiert dessen Port. Daher die Fehlermeldung im Logfile. Diese Ports (bis 1024) sind quasi "genormt", es sei denn Du hast die Port-Nummer(n) geändert - telnet ist normal port 23. Es wäre also nicht nur interessant ob Du den Dienst aktiviert hast, sondern - wenn JA und auf Standard Port 23 - welcher andere Dienst (Docker, Plugin) sich dazwischendrängt, weil das sollte nicht sein bzw. nur bewusst so gewollt sein. ...dann drücken wir mal die Daumen.

Verstehe nicht ganz, was Du damit meinst. Evtl. ist Dein "Problem", dass Du Daten-/Transaktionsbezogen denkst. Der Wert war ja schonmal da, warum nach dem Neustart nicht mehr? -> Weil das Sensordaten sind und ein Sensor ist Event-bezogen. Die Daten erscheinen also erst wieder im HA, wenn der Sensor neue Daten, bzw. die letzten wieder/nochmal einliefert (oder HA diese pollt/abholt)....bis dahin gibt es keinen Event, also per Definition keine Daten. ...ich persistiere alle Sensordaten in einer InfluxDB...alle meine Sensoren liefern über mqtt Events/Daten...telegraf holt die ab und pusht die in die InfluxDB...HA bedient sich auch bei mqtt. Grafen usw habe ich dann über Grafana-Dashboards aus der InfluxDB. Die Diagramme bei HA sind für mich nur Beiwerk....die Aktoren sind das, was mich in HA interessiert.

Nein, ich meine Telnet: https://de.wikipedia.org/wiki/Telnet Hast Du offenbar in den Settings unter "Management-Access" aktiviert...die Fehlermeldung besagt aber, das der Port (tcp:23) - oder welchen Du auch immer in unraid da eingestellt hast - belegt ist ... wahrscheinlich von einem Docker. Würde ich mal abstellen...müllt unnötig das Log zu und ein Port-Konflikt führt irgendwann mal zu Nebenwirkungen, wenn evtl. doch mal der andere Prozess zuerst Zugriff bekommt. Ok, ich tippe mal auf diesen "Fehler"....ansonsten eben eher Hardware. Nochmal die Frage, ob Du inzwischen mal einen Memtest gemacht hast? Memtest ist schon auf dem Stick mit drauf und beim boot-screen auswählbar (Tastatur und Bildschirm anschliessen).

....ok, man sieht da schon was, das nicht dahin gehört: ...davon hast Du sehr viele im Syslog....hast Du telnet als Service aktiviert? Irgendwas belegt aber den Port... ....Du nutzt Docker wohl mit macvlan ... stell mal auf ipvlan um....wenn Du ne Fritz hast...leb damit, dass die Hostnamen dann spinnen. ..das ist auch nicht nett. Solltest Du mal reparieren.....ist Disk2 ...da stimmt auch etwas nicht. ...kann ich nicht genau zuordnen....evtl. NCQ für die Disks??...bringt im Array auch nix. Hat Du irgendwas im BIOS zum Themo overclocking oder so eingestellt? Hast Du denn jetzt mal einen memtast laufen lassen?

Ich würde die zwei 14TB ins unRaid-Array nehmen...1x Parity, 1x Daten - der Vorteil mit nur 1x Daten-Disk im Array ist, dass unraid dann (doch) einen Mirror baut und damit die Performance nicht leidet. Die alten Disks dann als Backup (in der externen WD-Lösung, oder?). Die beiden 2TB dann als ein Pool ins unraid für "beliebige" Zwecke.....können ja da auch schlafen.

Plan B wäre, den Mover eben öfter laufen zu lassen (zB 1x/stunde, statt 1x/Tag - Wenn keine Daten zu verschieben sind, bleiben die Array-Disks dabei auch schlafend) oder ihn manuell oder über ein User-Script anzustossen. Es gibt für den Mover auch ein erweiteres Plugin mit mehr Einstellmöglichkeiten...

Netzteil, RAM, PCIe Karten.....11 Jahre ist ne stolze Zeit für ein NT.

v6.12rc7 ... gerade ein paar Studnen alt...die Platten sind da, aber angeblich kann das FS nicht eingehängt werden. Wenn das Aray inkl. Docker und Co. läuft, dann stimmt das wohl nicht. -> mach einen Bug Report im RC7 Faden auf. Alternativ, wenn Du kein ZFS brauchst/nutzen willst -> zurück auf die v6.11.5 gehen. Im Moment sehe ich keine Möglichkeit Deine Fehler (scheint mehr als ein Issue zu sein) irgendwie systematisch einzugrenzen.

....kannst Du einen Monitor und Tastatur anschliessen? Evtl. gibt es ja dann auf dem Monitor noch was zu sehen, was nicht im Logfile landet, wenn es wieder passiert. Hardware: die üblichen Verdächtigen wären zuerst RAM und Netzteil. ... danach dann PCIe Karten ...wie alt ist die Hardware?

Das ist ein LSI basierter No-Name Controller...angeblich sogar Raid (mit 512MB Cache - ohne BBU)....komisches Teil 🤔 Wenn das ein HBA ist (wozu dann Cache? - ist die HBA FW drauf?? Also, welche Firmware ist da drauf bzw. wie hast Du die HDDs konfiguriert (wenn RAID dann als JBOD?!?) -> die HDDs werden immer nur an diesem Controller nutzbar sein und evtl wird der (No-Name LSI/Broadcom) auch Probleme verursachen. Du muisst auf jeden Fall sicherstellen, das der die IT-Firmware drauf hat....ob der China Fake einen Flash mit Original-FW von Broadcom/LSI überlebt 🥴

Tjja, meine Glaskugel ist auch verschwommen....die Route brauchst Du, wenn das NAT im WG-Interface aus ist (das sorgt dafür, dass der Traffik aussieht, als ob er vom unraid Host selbst käme...ist NAT aus, ist die eigene IP des WG-Interface und der anderen WG-Teilnehmer im Heimnetz sichtbar. warum das bei die quasi nicht stabil, sondern dynamisch ist, erschliesst sich mir nicht.

Den gleichen oder den selben? Das war doch ein Intenso? Wenn es derselbe war, ist klar warum der blockiert/blacklisted ist. Wenn es nur ein gleicher war, ist jetzt wohl klar, dass der die gleiche GUID hat wie der/die anderen....also untauglich als Modell/Hersteller. Ich denke intenso kauft sich eh nur in China was zusammen.... SanDisk (Cruzer-Fit, -Blade), Transcend Jetflash sollten funktionieren. Allerings besteht in der heutigen, verrückten Welt die Chance, das auch von solchen Marken und von namhaften Händlern Fakes auf Deinem Tisch landen.

...kenne den Container nicht...aber im appdata Verzeichnis ist wirklich alles weg? Backups gemacht? ...jedes Update einspielen ist auch nicht immer nötig. Deine Entscheidung. Ich habe hier Container, die sind Jahre alt, weil ich Änderungen einer neuen Version nicht mitmachen wollte/konnte. Einfach den entsprechenden tag in den Einstellungen des Templates verwenden, statt "latest". ...ich glaube Du verwechselst Dein Rechte aufgrund (D)einer Lizenz und den damit verbundenen Lizenzbestimmungen mit den Bedinungen aus einem Kauf von Waren oder Dienstleistungen. Das sind zwei komplett verschiedene Dinge. Genauso wie das Thema "Open Source"...der Einsatz von OSS hat auch nicht automatisch damit zu tun, das man keine Rechte (und/oder gar Pflichten) hat. ...Dein Post war wohl eher ein Frust-Beitrag als eine konkrete Warnung an andere Nutzer des Containers Trotzdem wünsche ich Dir noch eine erfolgreiche Woche. 😇

...SR-IOV wäre ne Option, wenn die NIC eine Intel ist, die das kann. Edit: siehe

Ja, die Fritte ist weder ein "richtiger" Router nach kann die VLANs und hat keine konfigurierbare Firewall. Das einzige , was die zumindest erlaubt, wäre ein zweites Netz.....eine Router-VM auf unraid-Host könnte da helfen...aber ein zweier NIC für unraid wäre da Minimum um da die jeweiligen Docker anbinden.

...dann bleibt nur mit "Gewalt" über Filter/Forwarding-Rules im zentralen Router (der ja das Standardgateway ist)...geht aber nur mit nem "richtigen" Router und ist auch nicht einfach. ...dann geht es wohl so nicht

...klar..."einfach" über VLANs oder dedizierte, zweite Bridge (und NIC), wenn Du das entsprechende Equipment am Start hast.

Für das, was Du in Deinem Start-Post skizziert hast? Ja, auf jeden Fall...Schau mal hier: https://www.cpu-monkey.com/de/compare_cpu-intel_celeron_j6412-vs-intel_pentium_gold_g6405 Der Pentium hat CPU-seitig mehr Bumms, im Vergleich zum J6412, wenn mal Leistung benötigt wird....im idle wird er aber auch OK sein (Mobile-CPU und Mini-MB vs. Desktop und mATX sind da nicht direkt vergleichbar...das NT macht hier auch viel aus).....der IGP ist etwas schmalbrüstiger...dafür kann der Pentium auch ECC-Ram, falls Du doch mal auf ein Server-Board gehen willst. ... evtl. mal aufrüsten mit RAM, NICs, dGPU, SATA-Controller usw ist natürlich auch flexibler möglich.

Guter Hinweis! Ich hab mit dem B560 Chipatz auch keine Erfahrung und empfehle als Bass das B460M Pro 4 , eben mt 10th CPU. Hier, in der FAQ steht ...und das B560M Pro 4 kann das nur mit 11th gen. @one: warum das B560 und nicht das B460M Modell? Eine 11th gen CPU wäre dann ab i5...die Kombo mit Comet-Lake und B460M Pro 4 ist/bleibt günstiger und da gehen beide M.2 mit NVME

Die Toschibas verursachen/haben allerdings ab und an so ein "seuzfen" im Betrieb....im nicht schallgedämmten Gehäuse mag das störender sein, als ein Dauergeräusch.

Ja, genau .. sind zwei Schritte, immer mit Stop, Konfig-Änderung, Start Array.

Nein, es ändert sich überhaupt nix...ist nur eine alternative, neue Dokumentation

...dabei rennen halt alle HDDs lange, dauerhaft....klar, dass es da warm wird. Für diesen Fall muss man das designen, nicht für den Normalfall, wo durchschnittlich eine Platte allein im lesenden Zugriff ist oder der Mover mal 15min zu tun hat.

...es fällt auf, das die HDDs mal sehr, sehr heiss wurden...teilweise 68°C ... Du hast/hattest ein Problem mit der Luftzirkulation. Für mich ist bei HDDs bei 40°C bereits eine Warnstufe und bei 50°C das absolute Ende erreicht...wärmer als 39°C sollten die eigentlich nicht werden. Da würde ich mal was machen, auch wenn die HDDs bisher durchgehalten haben.