Ford Prefect

Ja, das weckt die Disks auf. Mach mal einen Bug Report im rc5 Faden auf -> https://forums.unraid.net/bug-reports/prereleases/ ...Diagnostics nicht vergessen.

verstehe ich nicht ganz...also welches Kabel...Strom-Kabel oder SATA-Kabel (Daten)? Diese Adapter sind im besten Fall zufällig OK, im Schlimmsten Fall eine Ursache für Rauchzeichen aus der Box. Kannst Du den austauschen? Einen direkten SATA-Stromanschluss aus dem NT verwenden um die Disk zu testen? ...bei 2HDDs hast Du da doch noch was übrig, hoffe ich. Das käme auf das NT an... beim Booten brauchen HDDs viel Strom...jede einzelne um die 25W an 12V für den Motor-Start. Wie alt ist das NT bzw. welches Modell ist es?

...bootete der Stick da schon über UEFI? Wie heisst der Ordner auf den Stick: "EFI" oder "_EFI" ? -> für UEFI boot muss er "EFI" heissen. -> umbenennen.

wenn Parity nicht geht, ist die ganze DIsk futsch, mit allen Dateien da drauf. Zurück zu Deinem Problem: ...oben sieht man das doch eine Daten Disk schäft. Hast Du mal bei den Shares "alle berechnen" gemacht? sind die Daten, die auf Cache gehören wirklich alle nur auf Cache? Wo sind die Docker-Images / Container? Da gibt es einen Hinweis, in den 6.12RCx wie man das machen soll, für Docker im Verzeichnisbaum, statt im IMG bei den Docker Einstellungen.

Was macht er denn, wenn Du ohne Stick bootest...sagt er dann sowas wie "no media" oder landest Du wieder im BIOS? Da gibt es vielleicht eine Einstellung, die das verursacht, wenn kein Boot-Medium gefunden wird -> dann ist der Stick doch kein richtiges Bootmedium aus der Sicht des Boards...evtl mal BIOS Update machen? Edit: im POST Bildschirm müsste zuerst noch die Option F12 kommen um das Medium nochmal auswählen zu können. Geht es damit?

Jetzt sprichst Du in Rätseln...nur für Insider, die das Plugin/den Docker kennen?...oder doch in der Fritz? ...hast Du Kinder ? Schlafwandelst Du? Hast Du esoterische Erfahrungen oder psychodelische Pilze in der Bio-Kiste? Computer sind doof und dazu da Probleme zu lösen, die wir ohne die Dinger gar nicht hätten. Nimm es hin, irgendwas ist passiert..entweder vor der Tastatur oder automagisch.

Da kann sie erst auftauchen, wenn sie physisch im System auftaucht um sie danach in die Array-Konfig aufnehmen zu können. Das gibt es an dem Ort auch garnicht. Was sagt ein "ls /dev/disk/by-id/" wenn Du die Platte eingebaut und verkabelt hast? Was für ne DIsk ist das und wie genau schliesst Du die an? Stromversorgung prüfen...nutzt Du irgendwelche Adapter (Molex -> SATA)?

jo. das ist Ansichstsache, aber ist nicht verkehrt. In der Fritz...brauchst Du aber nicht, wenn unraid-Seite NAT macht. ...den letzten Teil würde ich jetzt nicht unterschreiben, aber wahrscheinlich. Wie sieht die Access-List für die WG-Peers im unraid aus? Welche Netzwerk-Konfig hast Du für den WG-Docker (ist doch ein Docker?) dort aktiv (bridge, host, custom-Bridge)? Welches Netzwerk-Modus hat Du in den allg. Docker Settings bei unrad (macvlan oder ipvlan?) Wie viele WG-Peers hast Du definiert und hat jeder eine eigene WG-IP oder ist da was doppelt? ...mehr Ideen habe ich aktuell nicht zu bieten.

genau genommen bringt Dir ZFS (oder BTRFS) im Array nix, gegenüber XFS - Copy-on-Write detektiert den Fehler, kann ihn aber nicht heilen (mangels alternativem vdev im pool - der eben nur aus einer Disk besteht)...es springt eh die Parity ein. Im unraid-Pool (primary Storage) macht ZFS sehr viel Sinn.

Was steht in der WG-App auf dem Phone bei erlaubte IPs beim Teilnehmer (dem unraid Server)? Das muss 0.0.0.0/0 stehen, damit die DNS-Anfragen vom Phone auch durch den Tunnel gehen. hier brauchst Du nix hochladen...fiinde raus, ob das ping zum Google DNS über den tunnel geht oder über das lokale I-Net. Wenn die unraid IP da auftaucht bzw. die WG-IP geht es über den Tunnel. Dann ist das Problem nicht auf dem Phone, sondern entweder in der WG-Konfig auf Unraid oder auf der Fritz. Mit ping testen ob das Ziel erreichbar ist...dann mit traceroute testen und schauen über welche "hops"/IPs das Ziel angesprungen wird. NAT ist auf der Seite des unraid-WG. Mit NAT "an", sehen Pakete aus dem WG-Interface aus, als ob sie von der lokalen IP des unraid-Host/des Dockers kommen. Das Netz kennt die Fritz ja (heimnetz). Mit NAT "aus" kommen die Pakete mit der IP des WG-Inteface des Phones (diese IP steht im Phone iin der WG-App unter "Interface -> Adressen". Das Netz kennt die Fritz nicht...die pakete kommen bei der Fritz an, aber sie kann die nicht zurückschicken -> Route in der Fritz eintragen für das WG-Netz mit GIP-des unraid Host im Heimnetz als Gateway. ...zumindest ist das meine Vermutung, ohne jetzt den unRaid Docker/Plugin zu kennen. Quatsch...das ist eine IPSec, verschlüssselte Verbindung. Wenn AVM da mithört wären die längst tot. ...willentlich geändert. Kann ja viel passieren - auto Updates hier und da, inkl. auch FritzOS. Wie gesagt, ich kann da nicht viel helfen, da ich WG nicht auf unraid nutze...mache das mit einem "echten" Router, nicht ner Fritz.

OK, das ist doof. Dann da mal gegenchecken....evtl hast Du doch eine neue IP bekommen und da liegt das Problem - obwohl, dann sollte Android sich garnicht verbinden können?

Du musst auch dem WG auf dem Phone sagen, dass alles durch den Tunnel geht. Bist Du sicher, dass es da noch korrekt konfiguriert ist und das es das auch tut? Installiere mal Ping & Net Tools und mache vom Android ein Traceroute auf 8.8.8.8 (Google DNS). Je nach NAT Einstellungen auf Unraid/WG-Server-Seite musst Du das Transfer-Netz des WG auch in der Fritz als Route auf den unraid-Host als Gateway definieren. Evtl. ist das verrutscht? Ich nutze selbst das Plugin / Docker-App nicht, kann leider nicht so viel helfen...ping und traceroute aus beiden Richtungen um den Fehler einzugrenzen, wo die Pakete hängen bleiben, dabei Hin- und Rückrichtung testen/beachten.

Edit: ich denke Du hast einfach nicht verstanden wie in unraid das Array und die Pools als Konzept funktionieren. Warum geht es nicht: Weil Du einen zpool, der aus mehr als einer Disk besteht gebaut hast und den in einen unrad-pool eingebaut hast. Im Array ist jede Disk einzeln formatiert, bei XFS, BTRFS und auch ZFS ... also bei ZFS ein zpool aus einer Disk...da hat auch ZFS keine Redundanz in dieser einen DIsk, aber im Array gibt es die Option der Parity DIsk, die für die Redundanz sorgt...die ist unabhängig vom verwendeten Dateisystem, dann immer da...das ist das "geniale" im Array...dafür gibt es auch Nachteile, zB Performance (kein striping). Edit: Selbst wenn einzelne Disks ausfallen, auch mehr als durch Parity gedeckt sind, bleiben die übrigen unversehrt, weil einzelne Disk, einzeln formatiert -> jede Datei ist immer vollständig und nur auf einer Disk (kein striping)....also kannst Du die einzeln wieder mounten. In einem unraid-Pool musst Du selbst für Redundanz sorgen wenn Du das willst....also den "richtigen" Raid-Level auswählen....bei XFS geht das garnicht, bei BTRFS geht es und bei ZFS auch. Beim zpool Backup hast Du das offensichtlich nicht getan (NULL Redundanz im Raid-Level mit striping)...im zpool Daten sind einfach mehr Disks (3) futsch als Redundanz vorhanden war (2, weil raidz2 - auch ein Raid-Level mit striping aber Parity).

Well, as I said, I don't know either. Assess the risk involved....what could go wrong? I'd disable auto start of docker containers (avoiding that defective changes persist in their appdata folder) Install an extra Docker for testing deactivate docker deamon in settings create the file (in RAM) restart docker deamon check if file is still there assess if this is working and what side effects are there (as you read somewhere) as you change the way doocker deamon does logging, the log entries in each container are possibly different, corrupt or similar? if everthing runs fine, edit the go fille - if there are problems, reboot and everything should be as normal as it was before ...use a test system, not the unraid production box to kepp the WAF up

just a hunch here...if this fiile is not available, why not simply create it? As unraid is running in RAM only, you could make it persistant by adding a command in your GO file on the Stick -> create the file, save on the boot stick, then copy it into /etc/docker/ when booting by adding the copy command to the GO file.

....Du hast da oben 2 zpools gelistet....die sind beide am Irsch...egal ob es unraid pools waren/sind oder in welchem OS/Sytem auch immer. Ein zpool kann ein unraid-pool sein, aber das macht ihn nicht zu einem andern Pool-Typ. Diese beiden zpools kannst Du nicht wiederherstellen oder reparieren.

Ja, das ist tödlich. Der zpool "backup" ist ein sogenannter "striped pool" (ähnlich wie ein JBOD) -> NULL Redundanz, fällt eine Disk aus, ist alles weg - das ist bei Dir der Fall. Der zpool "Daten" ins ein raidz2 ... da gibt es Redundanz für zwei DIsks -> ebenfalls Totalausfall., da drei von fünf DIsks weg sind. btw: woher sind die vdevs da eingebunden? sind das iSCSI Devices oder über disk-by-Id? Kommst Du bei iSCSI da doch da noch dran?

Your're welcome. Best way to test is using other Clients on the network or VMs (with dedicated NICs or virtio NICs on the individaul unraid bridge, like br0.10 for VLAN10). Test if the client-OS will receive an IP from the dedicated DHCP-pool, assigned to that VLAN from your Router/DHCP-Server. For all - clients, dockers and VMs - use tools like ping, traceroute, iperf3 to test performance and the paths a packet takes when traversing through your network. I am using mikrotiik gear. A benefit is, that you can use mikrotik RouterOS in a VM as well, with very low ressources (a RouterOS VM only needs 200MB RAM, 1vCPU and 1-2GB vdisk)....with dedicated, passed-through NICs and a spare unraid testbox, one can setup a sandbox to test...keeps the WAF up high Ah, someone who knows the good old ways of how the world works...I appreciate that 🤩 Let me know how things progress on your side and ask questions, if need be..I'll try to help and promise to not turn into a BOFH

...sollte die denn übberhaupt mit BTRFS formatiert sein? Dann -> für ZFS: was sagt denn ein "zpool import" in der CLI?

Der "standard" ist es die Docker Container (Pfad in den unraud Docker Settings) und die persistenten Daten (die einen Comntainer-Restart überleben sollen - das ist standardmässig unter /nm,nt/user/appdataa/<dein Docker>) komplett auf dem Cache zu belassen. Mit ZFS auf dem Cache-Pool kannst Du ein Raid1 (Mirror) oder auch ein raidz nutzen (mit ZFS-parität - und striping). Aber auch ein Mirror hat Redundanz. Lies mal hier: https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/ Wenn Du einen Mirror aus zwei Devices baust, kann eines wegfallen, weil immer noch eines/das verbleibende alle Daten/Blöcke hat. Ja, mach das...siehe oben....Raid1 ist quasi auch hier standard. Ja, macht Sinn. Du kannst in unraid ja erstmal das Array ohne Parity, mit der neuen 18TB als Daten-Disk #1 aufbauen .. dann die Daten übertragen....dann die Disks nach-und-nach auf diese Weise "umziehen" in den unraid Server. Meine Empfehlung, vor allem wenn Du backups hast, wäre es die Parity Disk (das ist dann Deine "alte" 18TB) zuletzt hinzuzufügen (sonst wird die bei jedem Neustart des Array/jeder Array-Konfig-Änderung neu gebaut, was auch Stress für die Disks ist und bei 18TB schon kleine (Lange-)Weile dauert.

Ja genau so wird es gemacht. Allerdings für Docker brauchst Du nur das "appdata" Verzeichnis (oder was immer Du da konfiguriert hast um die Daten über Container-Starts hinweg zu sichern) ... die Docker images brauchst Du nicht (wenn als Verzeichnis abgelegt würde ich das vorher manuell löschen, sonst dauert das Verschieben ewig). Nachteil dazu: wenn Du im Docker template "latest" definiert hast (was i.d.R. der standard ist), Du aber bewusst mal einen Docker nicht ge-updated hast weil Du die "latest" nicht haben wolltest / auf der lokal installierten Version bleien wolltest, wirst Du die latest dann nach der Aktion doch bekommen -> vorher die Version fixieren (Beispiel influxDB:1.8 ...latest ist 2.x oder gar 3.0 - wo sich auch intern was geändert hat und die Daten-Migration auch Probleme machen könnte).

...warte mal ab, bis die Kids flügge werden....die kommen dann schon auf die Ideen, wie sie die Sites ansurfen können wo man Menschen sieht, die so arm sind, dass die sich keine Kleider leisten können Na, das hast du ja schonmal verstanden...mit einer Fritz kannst Du das aber garnicht feststellen, dass Clients das umgehen....hast also kein ToDo. Der Hinweis ging auch nicht nur in Deine Richtung...der Faden ist ja nicht Deiner.

Das ist dem Grunde nach aber eine falsche Annahme. Die Fitz vergibt lediglich mittels DHCP die IP und auch die DNS-Server für den Client. Entweder stellt man dort in der DHCP Config ein, dass DNS die IP des Adguard ist, sodass diese IP direkt vom Client bei DNS-Anfragen verwendet wird oder man stellt den Adguard Server als DNS für die Fritz ein, welche wiederum dann sich selbst als DNS-Server an die Clients ausgibt. In beiden Fällen würde der Client letztlich den Adguard Server als DNS verwenden. ...würde, denn die Fritz forciert aber nicht, dass Clients dies tun. Stellt man im Client manuell einen DNS-Server ein, so können diese einen DNS Server an der Fritz/Adguard vorbei nutzen. Eine Einstellung in der Fritz-Firewall, dies zu verhindern kann man mMn nicht vornehmen - nötig wäre ein Port-Forwarding für alle DNS-Anfragen aus dem Heimnetz an den Adguard-Server (ausser es ist der Adguard-Server selbst ). Mit DNSsec / DoH wäre aber auch das nicht forcierbar, da nicht der DNS Standard-Port verwendet wird....allein die Berechtigungen im Client selbst, den DNS-Server dort einstellbar zu machen, könnten das verhindern (oder man hat/pflegt eine Liste aller DoH/DNSsec Server für die Firewall-Regel).

In dem Post hat eben derjenige zwar das Problem, andere User aber eben nicht. Dort wird auch der Hinweis zur 6.12rc gegeben, auf die der Schreiber des Post nicht wechseln & testen kann...da Du aber unter 6.12rc3 das Problem hast, würde ich auf jeden Fall einen Bug-Report machen! Evtl. ein Workaround (mal laut gedacht): @ich777 kann man für den RT8125 einen anderen Treiber nachladen und den RT8169 Treiber blacklisten?

Naja, eben...deswegen ging es mit XFS/BTRFS im Array bei SSDs ja auch bislang nicht....wird halt mit ZFS nicht anders sein.