Ford Prefect

...auch bei SSD ist das Array nur so schnell wie eine Disk...bei einerm 10G oder gar 40G/100G Link ist das nicht zu schaffen...mit nem Pool auf Basis NVME und Striping dann schon.

...wie ich oben schon schrieb, zuerst die Docker und VM-Dienste unter Settings deaktivieren. Dann erst kann der Mover die Dateien verschieben, weil sie sonst von den Diensten im Zugriff sind. Das gleiche "Problem" hast Du auch mit domains (wo standardmässig Deine vdisks der VMs liegen). ...sind darunter auch Ordner und Datei(en)? Nur weil da "0 B" steht, muss das ja nicht stimmen...eine klitzekleine Datei reicht für die Warnung.

...und, nur um sicher zu sein, mal schauen, ob unter /mnt/cache das Verzeichnis appdata existiert und ob da doch was drin ist....

Nein, mit der Neukonfiguration des Array ist das "Problem" weg. Wenn die Parity eingehängt und gebaut/Parity-Check durch ist, sollte das einfach nicht so sein.... Bitte nochmal schauen, wie die Einstellung des Share "appdata" ist, was Primary und Secondary Storage angeht...kannst Du einen Screenshot machen/zeigen?

Wahrscheinlich sind die Daten eben (teilweise) nicht auf dem Array, sondern auf dem Cache (der nur eine, damit ungeschütze Disk, hat statt zB ein Raid1). Schau mal bei den Shares nach, mach für "appdate" ein "compute/berechne" und Du siehst, ob noch was auf Cache liegt. Wenn dem so ist, was ich vermute, dann musst Du die Docker- und VM-Dienste (unter den jeweiligen Settings) deaktivieren und dann den Mover laufen lassen. Wenn Du auf der 6.12 bist, schau vorher in den Share-Einstellungen ab "Primary = Array" ist und die Richtung, in die der Mover läuft, auch korrekt von Cache->Array steht.

Du kannst das relativ einfach testen/herausfinden, denn: mit macvlan bekommt jeder Docker (der im custom Netzwerk-Typ) eine eindeutge MAC-Adresse im Netzwerk mit IPvlan haben alle Docker im gleichen Netz, die gleiche MAC-Adresse...die identisch mit der MAC der Netzwerk-Karte/Bridge im unraid-Host ist. ...und testen könnte man so: Dazu installierst Du Dir einen Docker, zb Openspeedtest und nimmst dort als Netzwerkkonfiguration den NetzwerkTyp "custom.bridge" ... also zB br0 und stellst da eine feste, bislang nicht vergebene IP aus Deinem Netzwerk ein, zB so: Dann nimmst Du einen LAN-Client (Laptop, Desktop) der im gleichen Netz ist und startest mal einen "openspeedtest" Danach das Eingabefenster/Kommandozeile des LAN-Client öffnen... ...einmal den unraid host anpingen, mit "ping <ip oder DNS.Name des unraid host>" ping 192.168.0.25 Ping wird ausgeführt für 192.168.0.25 mit 32 Bytes Daten: Antwort von 192.168.0.25: Bytes=32 Zeit=4ms TTL=64 Antwort von 192.168.0.25: Bytes=32 Zeit=2ms TTL=64 Ping-Statistik für 192.168.0.25: Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 2ms, Maximum = 4ms, Mittelwert = 3ms dann ein beherztes "arp -a" (für Windows, für Linux ein "arp -an") eingeben. dann sieht man zB sowas: arp -a Schnittstelle: 192.168.0.114 --- 0x15 Internetadresse Physische Adresse Typ 192.168.0.1 48-8f-5a-99-xx-xx dynamisch 192.168.0.11 f4-52-14-84-xx-xx dynamisch 192.168.0.25 f4-52-14-84-xx-xx dynamisch 192.168.0.101 7c-d5-66-17-xx-xx dynamisch ...mein Router hat die IP 192.168.0.1, der unraid host hat die IP 192.168.0.25 und der Docker die IP 192.168.0.11 -> ich nutze also ipvlan auf dem unraid host, da die beiden MACs der IPs im Kontext unraid (host + docker) identisch sind.

Also, um das nochmal eindeutiger zu formulieren: Du installierst auf dem VPS ein OS mit Wireguard auf dem VP richtest Du die "Peers" ein - und zwar Dein(e) Handy(s) und die Fritz auf der Fritz und auf dem/den Handy(s) richtest Du den VPS als Peer *und* auch als Endpunkt ein. Der Endpunkt ist die öffentliche IP des VPS. Das sorgt dafür, das der Tunnel zum Endpunkt von diesem Peer aufgebaut wird, wenn das Peer/WG aktiviert wird (Also Fritz baut zum VPS auf und Handy(s) bauen zum VPS auf - andersrum geht es ja nicht). Bei dem/den Handy(s) legst Du fest, dass auch Dein Heimnetz (zB IP 178.168.0.0/24) über WG erreicht werden kann/darf. fertsch ist Dein erstes Szenario ...aber (ohne jetzt zu wissen, ob es bei der Fritz wirklich so einstellbar ist) legst Du in der Fritte fest, das auch das I-Net (IP 0.0.0.0/0 - also "quasi alles" und nicht nur die WG-peers) über WG zum VPS erreichbar ist, entsteht das zweite Szenario *zusätzlich* ... der VPS wird zu Deinem WAN und LAN-Clients, die ins I-Net kommunizieren, werden durch den VPN dorthin getunnelt (Den NordVPN Beispiel - ob das die Fritz aber kann, weiss ich nicht). Um das zu verhindern, weil Du das ja garnicht willst, darfst Du der Fritz nur sgen, dass die Wireguard-Peers (deren interne IPs des WG-"mesh" - welche der VPS vergibt, zB 10.0.1.0/24) hinter dem WG-Peer des VPS liegen. Mit einem "richtigen" Router könntest Du das granular kombinieren und zB nur einzelne LAN-Clients über den VPS ins I-Net routen. ...hope it helps. Wie planst Du denn den VPS aufzusetzen?

Nein, schon wieder beides falsch, leider. ...das geht mit der Fritz *nicht* ...das (sollte) mit der Fritz gehen (hab ich aber selbst, mangels Fritz, nicht getestet. Bei beiden Szenarien aber nicht vergessen, dass der VPS ja auch einen WG-"Server" braucht - ungeachtet ob Fritz oder nicht. Den musst Du auch bereitstellen (und sicer machen). zB Mikrotik, mit RouterOS. Ich setze so einen u.a. auch auf dem VPS ein (nennt sich dann CHR - Cloud hosted Router) ...ist aber nicht kostenlos (ein Hardware Router hat RouterOS inkl. Lizenz an Board, ein CHR braucht eine Lizenz). ...die Lernkurve bei RouterOS ist noch "steiler".

...nur nochmal zur Klärung: Handy und PC sind beide lokal, in deinem Heimnetz verbunden, bei der Aktion? Oder hast Du Wireguard für die Verbindung von Aussen aktiviert oder gar Nextcloud über nen Proxy ins I-Net gebracht? Wie sieht das Sztenario für eine solche Variante genau aus, wenn der Fehler auftritt?

Wie gesagt, eine Fritz ist nicht wirklich flexibel, was Routing- und Firewall-Regeln angeht. Grundsätzlich muss die Fritz die Firmware v7.50 oder höher unterstützen, damit da Wireguard drauf/dabei ist. Nochmal zu Deinem Use-Case.... Das hier: ...und das hier: ....sind tatsächlich zwei verschiedene Dinge. Mein Verständnis ist, dass die Fritz, mit ihrer simplen Firewall nur den letzteren UseCase - den Du eben in Deinem ersten Post genannt hast - unterstützen kann. Also bitte mach Dir klar, was Du willst. Es gibt natürlich flexiblere, "richtige" (LTE-)Router...wenn Du aber keinen Plan von IP-Routing usw hast, ist das eine sehr, sehr steile Lernkurve. Eine Fritz ist da einfacher und mit der kannst Du umgehen, aber eben evtl. nicht jedes Szenario erreichen.

...ich vermute, Du musst Dir mal klar werden, wie IP-Routing funktioniert. Dein Szenario ist ja so, dass der Router einen WG-Tunnel zum VPS aufbaut. Damit gilt erstmal: WG-"Clients", welche über WG auf die öffentliche IP des VPS verbinden, bauen einen Tunnel zwischen Client und VPS auf und benutzen den weiteren, bestehenden Tunnel (Router-VPS) auch in Richtung Heimnetz mit (wenn richtig konfiguriert). Clients im Heimnetz nutzen i.A. ja gar keinen WG-Tunnel (sie sind ja schon im LAN). Damit würden Daten also nur über den Tunnel in Richtung VPS fliessen, wenn der Client IPs anspricht, die auf der anderen Seite des Tunnels liegen (entweder andere WG-Clients oder auch das I-Net - wenn der Client nicht Deine lokale WAN-IP, sondern die IP des VPS als "Ausgangs/Absender"-Adresse verwenden soll. Per default leitet der Router also nicht "alle Cients im Haushalt" über den Tunnel. Natürlich könntest Du es so konfigurieren, das die öffentliche IP des VPS praktisch "für Alle im Heimnetz" (oder gezielte/einige) dein "WAN" ist. ...man muss es also richtig konfigurieren. Mit einer Fritte geht das auch nicht optimal, aber die würde auch defaultmässig es so nicht einstellen. s.o...."falsche" Regeln in der Firewall / im Routing konfiguriert...tja, dann kann das passieren. Man muss wissen, was man tut (und auch keine Fritte dafür einsetzen, denn da kann man keine besonderen Regeln einstellen).

...hast Du ne (d)GPU durchgeschleift? Evtl. ist die Einstellung in vfio-pci verloren gegangen?

Klugscheisser Mode ON: 2GByte/sec: https://de.wikipedia.org/wiki/PCI_Express#Technik ...also knapp an einem 10Gbit/sec Full-Duplex Kanal.

Ja, wobei ich bisher davon ausgegangen war, dass es eben Rückläufer aus Widerrufen sind, also nicht älter als 30Tage (60 bei Sonderaktionen zu Weihnachten/Sylvester)...keine Garantie-Rückläufer die 1.3 Jahre auf dem Buckel haben und eben auch schon hunderte TB durchgelutscht wurden.

...das mach mal sofort dicht!!! ...in der Diagnostics finde ich nix...auch kein verdächtiges Plugin oder auto-start im GO-File...die logs sind ja von einem Neustart heute Morgen. Schau mal auf Deinem Array oder Cache, ob da irgendwas abgelegt ist, das "watchdogg" heisst. Edit: und lies mal hier, was Du abstellen solltest.

nur am Rande, ich habe hier gerade Feedback von einem neuen User, der sich NVMe aus Amazon Warehouse deals geholt hatte...da waren welche dabei, die hatten im SMART Report schon 10k Betriebsstunden 🥴 ... da hat wohl jemand Neue bestellt und seine Alten zurückgesendet...amazon prüft wohl keine S/N??? 🤮

Hast Du Deinen Server ins I-Net gehängt, mit Zugriff von Aussen? Dann wird der evtl. nicht dicht / aabgesichert sein. Unraid bootet vom RAM...entweder hast Du/Dir jemand einen Docker installiert oder zB was direkt untergejubelt zb als Plugin getarnt und/oder im GO-File dann beim boot aktiviert. Poste mal Deine Diagnostics.zip ...loswerden ist das Eine (Array Config abfotografieren und den Stick komplett platt machen/neu aufbauen....nur Deinen Lizenzfile dazugeben). Aber das Warum/Server absichern ist dann Dein eigentliches Problem. Siehe auch:

...nur als Ergänzung, ich habe meine Desktops und unraid-Host auch mit DAC (ConnectX-3) angeschlossen...dazwischen liegt aber eine Strecke zwischen den Etagen-Switches über 18m CAT5e und 10G-T Transceivern (fs.com 80m und MT S-RJ10)...

Google ist voll von Kandidaten, wenn man nach Shelly, mqtt, node-red und nulleinspeisung sucht. Der 3EM Pro kann (noch) kein Tamota...aber auch mit der Standard-Firmware geht mqtt. Ansonsten gibt es wohl auch Node-Red Bibliotheken für die API...musst Du schauen, ob die mit dem neuen 3EM Pro gehen....im Zweifel wird der passende Webhook und Aufbau des calls in der API zu finden sein. Edit: schau auch mal hier: https://www.akkudoktor.net/forum/postid/62943/ openDTU und Einspeiselimit per mqtt / Node-Red soll wohl gehen. Sorry, ich bin echter und überzeugter Überschusseinspeiser ... kann nicht konkreter für dein Setup helfen Das thema Nicht-Anmeldung des BKW lassen wir mal aussen vor....das könnte sich in Zukunft anders entwickeln, als bisher....just sayin'

Es gibt auch das Plugin "un-get" von @ich777, hier: https://github.com/ich777/un-get Damit kann mal faktisch alles aus der Slackware-Distro installieren. Sehr schlank...zumal es mit den nerd-tools in der Vergangenheit probleme gab. Da nimmst Du doch bestimmt Docker für.... Der Shelly kann, wie alle shellys ja auch mqtt ... könnte man ja auch mit Node-red machen oder iobroker? Wieso muss es python sein? Ich bin da eher dafür, auf unraid funktionale Erweiterungen für andere Dinge/Services als unraid sauber zu trennen.

...in den "guten, alten Zeiten" hatten Desktop Platten sogar eine viel höhere, erlaubte Start/Stop-Count Rate....heute gibt es immer noch Unterschiede aber nicht mehr in wirklich relevanter Höhe....alle haben viele Hunderttausend Zyklen. Gerade mal schnell auf Datenblätter geschaut...Eine WD-Black (Desktop-Gaminig, 7.2kRPM) hat gegenüber einer WD Red Pus (NAS 5.4kRPM) sogar nur die Hälfte - 300tsd vs 600tsd Zyklen - also umgekehrte Situation als früher 🤪

man könnte beim Mover das Logging aktivieren und im Log nach dem letzten "Starttext" suchen und den den zeitlich nachfoigenden "Schlusstext" finden, oder noch darauf warten: Jun 14 08:00:01 alarm root: mover: started [...] Jun 14 08:00:01 alarm root: mover: finished

....ist genau genommen, grundsätzlich nie nötig. Ist Geschmackssache...für mich liegt der Unterschied in der Garantiezeit....ich nehme nur noch welche mit 5 Jahren....das sind dann eben NAS/Enterprise Disks. Hat man viele HDDs direkt nebeneinander im Gehäuse, sollen NAS Platten gegen Vibrationen aus dem Umfeld (drehende "Schwungscheiben" der Nachbar-HDDs) besser geschützt/robuster sein. Ausserdem haben die NAS DIsks in der Regel wohl einen etwas höheren, akzeptierten Temperaturbereich im oberen Feld (typisch 65°C statt 55-60°C bei aktuellen Modellen)...aber da versucht man eh deutlich drunter zu bleiben. ...korrekt. ...auch beim Schreiben läuft nur die Parity (wenn vorhanden) und die jeweilige Disks (je nach eingestellter Allocation Method und Split-Level am share) - wenn man nicht Turbo-Write Mode aktiviert hat. Wenn Du die Daten via SSD-Cache Pool einspielst kann Dir die Performance der Disks quasi egal sein....für die Medienwiedergabe reichen auch die "langsam" drehenden HDDs. Fazit: ich würde dir jetzt nicht widersprechen

@nixweis gib mal im unraid-Terminal (das Icon ">_", rechts oben) ein: "lsof -n -P -i TCP:23 -E" ...falls der Port noch telnet/23 ist. root@alarm:~# lsof -n -P -i TCP:23 -E COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME inetd 7529 root 5u IPv4 21072 0t0 TCP *:23 (LISTEN) ...was sieht man bei dir?

Ja, Jein...Es können *keine* VMS sein. ...grundsätzlich können also alle diese Dinge einen Port (hier tcp/23 für telnet) nuitzen und unter Umständen den telnetd/inetd des unraud-OS "blockiern: Ja, weil: Docker, wenn sie "host" oder "bridge" Netzwerk-Modell nutzen. Schau im Docker-Tab, welche ports (TCP/23) auf Host-Seite gemappt sind. Plugins laufen nativ im unraid-OS, können also "alles" machen. Jein, weil: Es gibt auch Plugins, die andere Tools/Programme beim Start "nachinstallieren", zB das Nerd-Plugin (gibt es das noch?) oder das un-get Plugin von @ich777 ...oder Du/man legt manuell ein slackware "Programm" auf den Stick und startet das DIng im GO-File...