Ford Prefect

Nein, da gibt es mMn nach nix. In Deiner Diagnostics steht, dass flow-control off ist, was OK/richtig ist. Wie oben gesagt sind realtek NICs unter Linux immer problematisch. Der Treiber kommt nicht von unraid/limetech, sondern realtek stellt den im Linux Kernel bereit. In Deiner Diagnostics steht, dass der NIC auf der anderen Seite (Win 11) auch 5Gbps zum sync anbietet....es werden dann zwar 2.5G ge-synct, probier aber mal trotzdem dort (Win 11) fix auf 2.5G zu stellen. Edit: oder ist da ein Switch dazwischen? Dann dort den Port fix auf 2.5G stellen. Wenn man hier nach dem Modell sucht gibt es gemischte Infos dazu. Für Dein MB findet sich nix. Evtl. hier nochmal nach nem BIOS Update suchen und auch im BIOS alle ASPM/Stromspar Features erstmal aus. Evtl. im 6.12RC Faden einen Bug-Report aufmachen. Evtl auch mit iperf3 die Netzwerk-Performance erstmal allein testen ... evtl. sind es mit SMB dann andere/weitere Effekte die mit dem NIC aufschlagen.

Der Befehl "zpool import" sollte Dir die zpools auflisten, die Du importieren kannst. Das macht ja grundsätzlich erstmal nix. Unassigned Devices kann auch zpools/ZFS mounten Was für einen Error gibt er konkret aus? ...oder sagt er nur "no pools available to import" ...das ist ja an sich kein Fehler, ohne genau zu wissen ob der Pool wirklich noch da ist. Hast Du denn dabei auch den unraid-pool als zpool mit identischer zraid Konfiguration und als zfs-encrypted definiert, wie zuvor? Ohne encryption würde wohl die Frage nach Formatierung kommen, denke ich. Wenn es das encrypted Thema nicht löst: Was ist, wenn Du "zpool import" ausführst bevor der unraid-pool in der Konfig definiert ist und/oder ohne dass das Array gestartet ist? zpool import würde Dir erstmal den/die pools anzeigen und sagen, ob der importierbar ist. (Mein) letzter Versuch wäre ein "zpool import -D -l -f Backup" (wenn der zpool Backup hiess, das -l (kleines L) ist für die Frage nach dem secret)...Ist der zpool durch import nicht zu finden, ist er wohl wirklich futsch.

...siehe oben...ich hatte die Vermutung, dass dies hier auch passiert ist.

...was soll daran jetzt logisch sein? Das hat nix mit unraid zu tun, sondern dass Du Dich mit ZFS nicht auskennst. Ich hab Dir gleich oben schon den Hinweis zum Thema importieren eines pools gegeben...hast Du das jetzt mal versucht? wenn es ein zpool als raidz gebaut ist, keine Disks aus dem unraid-Array war, kannst Du die nicht einzeln auslesen, weil die Daten über die Disks verteilt (gestriped) sind. Das ist ZFS...egal ob unraid pool oder unraid array oder trueNAS oder Oracle Solaris....Du musst den zpool importieren...siehe meinen ersten Kommentar oben.

Yes, that's why I suggested to go that route, as you obviously have the gear in place This is just the way of thinking what a default firewall config would look like. In a more conservative/risk-aware setting you typically block everything first, then open up "the holes". Makes it easier to block everything when things go havoc. Hmmm...OK...what I was trying to say, was that you do not need to mix "normal" networking settings and Docker networking setting. Think IP-networking only and use VLANs iin the "normal" networking settings. Do not confuse MACVLANs with VLANs...MACVLANS (or IPVLANS) is just a concept of the Docker daemon on how Docker-networking is managed internally. On the Outside - how a running Docker containers get presented to the world, networking wise...it is "just" IP-networking (the only difference is with MACVLANs, each Container will present itself with a distinguished MAC, with IPVLANs all Containers will be seen as coming/going through from the same MAC - but with different IPs. This is in fact the case with most SoHo Routers/Gateways...and actually confirms to me, that dropping unify equipment was the right descision to me ;-). It is a faulty assumption that there needs to be a 1:1 relationship between MAC(L2) and IP(L3) in a client table. To me, using MACVLANs does not make much sense, as Dockers don't use real DHCP to acquire an IP (the dhcp-pool setting in unraid is a workaround and I don't use it). Maybe a use case around IEEE 802.1X authentication in a VLAN context might change that view, but I am also not using that, so did not test. Maybe you are right and yes, I did have lots of stability problems with using MACVLANs...moving to IPVLANs made these go away for me. As you loose the 1:1 relationship between MAC and IP, there is no simple way to automagically create a central client table (with (DNS-)name, MAC, IP). The real use behind that such a table is to have the (DNS-)name and IP "linked" in order to address the Dockeer service either by IP or Name. The MAC itsself doesn't really count (assuming you do not use it in a firewall rule) but obviously is used in unify gear to create that table automatically from ARP requests going through the Switch/Router. So this is an inconvenience, as I see it. All it takes is to create a static DNS entry for name and IP in your Router and/or DNS-Server once you create a Docker and assign a static IP in unraid. So for me, moving over to IPVLANs was the easier part, rather than trying to stick to MACVLANs by doing other quirks in the unraid settings, like you did. That's "normal"...the gateway in each VLAN is specified in the standard network settings and is acknowledged/used just fine, regardless of it disapearing in the Docker settings view. When enabling VLANs, the gateway in the routing table for each VLAN is reported/becomes the interface (like br0.10), not the gateway-IP (like 192.168.10.1 for VLAN-ID 10)...maybe this is causing the "glitch" in the Docker settings UI. If this does not work for you, maybe you did something wrong with your VLAN setting (either in unraid or in the Router). That's why I use bridged networking model in the standard networking settings in unraid. Just assign a (virtio) NIC to the VM on the desired bridge. (which may cause problems when there ar MACVLAN Dockers on the same bridge, hence I switched to IPVLANs). This enables the fasted way of communication for network-services running on the same unraid Host (virtio in a VM gives you a "NIC" with the complete CPU-bandwidth - on my i8100 box, this gives approx 45Gbps - the same is true for a Docker using custom bridge networking). Another option is, of course. should you have spare, unused NIC in your host, to use IOMMU passthrough for the VM and connect it directly to the physical Switch. Which is what I do for most of my VMs (where I cannot find or make a suitable Docker setup for)...I have a spare i350-T4 card in my unraid host for this. Simply put: As you have the gear, move completely to a VLAN based setup. This will enable you to separate traffic for different services on your unraid host (Dockers and VMs)...which is what you want to achieve. VLAN setup works fine if correctly configured (on both sides, unraid and Router/Switches)...if it doesn't work for you, the problem is not a bug in unraid. ...maybe draw a diagram of what you want and how each physical NIC/LAN-Port and virtual LAN-Port comes into play and needs to be deployed, in order to get yor head around it. When it comes to thinking VLANs, the first concept that needs to be understood is that of Trunk- and Acces-Ports for physical ports in the multi-homed Host and/or a Router/Switch.

....interesting statement. IMHO - as WiFi is a shared medium, with impact from distance and other obstacles for good reception and even though these features like mumimo and beamforming exist - there is usually a factor of 10 between LAN and WiFi bandwidth to be seen ...meaning in order to transfer data end-2-end between client & Server at, for example, 10Mbps (1MB/sec), you need a 10+Mbps LAN-Link or a 100+Mbps WiFi Link. This basically confirmes it: https://www.tomshardware.com/features/wi-fi-6-and-6e-explained Is this a PCIe card? You could try and passthrough this to a router VM (if the OS inside has drivers for it), like openWRT or opnsense/pfsense, using a virtio NIC for LAN in the VM (which should give you max CPU bandwidth internally into the unraid Host - typically something between 8 to 50+Gbps, depending on your platform used.) What WiFi clients are you planning to use in order to create & sustain a 6Gbps Link - not even talking about a 6Gbps data transfer (see my first statement)

The proper way of doing this is with VLANs. Since my primary 10G NIC is sufficient for all my needs, I disabled all other NICs on the unraid host, allowing pass-trough of these NICs to VMs. But you could use unraid NICs as trunk (multipe VLAN-IDs, one NIC) or access ports (one NIC, one VLAN-ID) just like you would do with a switch. Also using LACP/bonding is possible with the right Switch on the other side. This is only a matter of (V)LAN settings, not Docker networking as such. I am only using custom.networks for Dockers (static IPs) - and ipvlans, as macvlan caused some problems in the past. Since Dockers don't do DHCP, there is no real use for macvlans....maybe besides some 802.1X auth usecases, I think. For each (set of) LAN-Port(s) - plural/set when bonding is used - individually used (either trunk or access-port) I recommend to create an individual bridge. Note, as a side effect when using VLANs, you need a VLAN capable router in order to allow inter-VLAN traffic, even between Dockers on the same Host (but on different networks)

Mir ging es auch um das:

Naja, es gibt Docker, die einfach die Arbeit einstellen, wenn zB der zusätzlich benötigte Docker, der die Datenbank bereitstellt, beim Start nicht vorhanden ist. Dazu gehört zB telegraf (der IoT Daten zB vom MQTT-Broker sammelt und in eine InfluxDB pusht). Allerdings würde man dann sehen, dass der Docker eben nicht (mehr) gestartet ist.

nimm ipvlan...ist stabiler Die Richtung des Verbindungsaufbaus ist wichtg. Natürlich kann der unraid Host auf die Docker zugreifen....nur nicht anders herum (Siherheitsfeature - s.o. wie man das abschalten kann) Wenn Du das aber erreichen willst, ohne das Sicherheitsfeature auszuschalten (warum eigentlich, wenn alle Dienste doch in Dockern sind - Docker können sich gegenseitig erreichen) musst Du VLANs (und NAT) nutzen. Ja, aber ohne ein "wait" >0 starten die faktisch (fast) gleichzeitg. Siehe: https://wiki.unraid.net/Manual/Docker_Management#Controlling_container_auto-start

...das mit der ohmschen Last meinte ich tatsächlich Ernst....bei Wechselstrom gibt es Wirk- (Watt/W, P) und Scheinleistung (VA, Q). Eine rein ohmsche Last het einen Power-Faktor von 1 und daher immer reine Wirkleistung...das ist das, was auch Dein Stromzähler zählt zur Verbrauchsabrechnung. Das "schönste" wäre, Du hast eine Glühbirne oder Quarzlampe/Strahler...möglichst mit 100W oder auch mehr....60W gehen aber auch. Messgerät "kalibrieren", also Messgerät an die Steckdose und Glühbirne ans Messgerät -> was wird angezeigt (zB 99W, statt 100W) -> 1% Messfehler Messgerät an die Steckdose, USV ans Messgerät und nur die Glühbirne an die USV (kein PC, keine Netzteile) -> was wird angezeigt (zB 120W) -> 20W gehen auf die USV...1% Messfehler -> USV Eigenverbrauch 18.8W

Dir ist schon klar, dass Du Deinen unraid-Server den bösen Menschen und Bots präsentierst? Verzeih, aber ich habe den Eindruck, dass Du in der Thematik nicht ganz so sattelfest bist. Da Risiko ist nicht unbedeutend. Evtl. wäre es einfacher, auf jeden Fall sicherer, ein VPN dazwischen zu schalten....welche Fritz hast Du genau? Evtl kann die schon WIreguard mit FrituOS 7.5x oder Fritz-Labor. Das lässt vermuten, dass der Docket im Host oder Bridge Mode läuft, weil 172er IP. Versuche mal den Docker auf custom-network, dabei auf br0 und fester, eigener IP aus Deinem IP-Segment laufen zu lassen. Wie genau hast Du die Freigaben inder Fritz gemacht? Auf die IP des unraid Host (192er)? Dann stelle diese Freigaben auf die dann neue, feste IP für den Docker um.

Dann ist das eigentlich kein Problem, das mit den Host-Zugriff für Docker zu tun hat. Evtl. spielen auch die Ports und die Reihenfolge der Docker-Starts für Dein Setup eine Rolle...von hier aus schwer zu sagen. Mit unraid Neustarts und gar doen-/up-grades sollte es nix zu tun haben. Hast Du die feste(n) IP(s) in ein anderes Netz-Segment und/oder über ein anderes Interface laufen? Grundsätzlich würde ich mal probieren alle diese Docker auf eine feste, individuelle IP in gleichen Netz/IP-Segment zu stellen. Dann ist diese Problematik mal aussen vor.

@Toysman Alternative wäre noch ein Asusstore: ..ob die CPU und vor allem RAM (8GB Version, die hat dann schon 6 HDD-Bays) ausreicht für Nextcloud wäre zu verifizieren. Auf jeden Fall nicht als VM, eher als Docker. Wer remote zugreift hat/bekommt/braucht eh nicht so viel Bandbreite...

Das Problem ist die Grösse des dann verwendbaren MB...miniTX -> max 4x SATA, kein Platz für 2x M.2 ... Wenn die Gehäusegrösse ein Problem ist...dann fang mal damit an eines zu suchen, das Dir noch passen würde. Am besten eben für ein mATX MB, Platz für 4x 3.5HDD + 2x 2.5HDD, am besten schallgedämmt, kein BigTower: hier

...hat Dein I-net denn eine echte öffentliche IP?

...das wäre schon i.O.....evtl. kannst Du das "Messding" mit ner Glühbirne (ohmsche Last) kalibrieren bzw. die Abweichung/Genaugkeit damit vorher messen (glücklich Derjenige, der noch ne 100W Glühbirne im Keller hat )....oder ist das ein richtiges Energie-Messgerät?

Hast/Kannst Du mal den Idle/Eigen-Verbrauch (ge)messen?

...mir ging es um den RAM...DDR3 oder DDR4 ... eher kein ECC, denke ich...die CPU ist/kann DDR3 und auch DDR4..DDR4 ist sparsamer. Habe ich keine Erfahrung mit...gibt es Rezensionen/Tests? Vielleicht liegt es auch am Elitedesk. ...siehe meinen Edit...eine Beispiel-Konfig ... unter 500EUR sollten ganz gut möglich sein, da Du schon die Disks hast. Ich würde in einen neuen Stick investieren. der konfigurierte ist mein Favorit, aber es gibt wohl viele Fakes inzwischen, siehe:

...wie alt sind die HDDs? aber eher eines der beiden letzteren Möglichkeiten, denke ich. Was genaau ist das für ein 2-Bay case? Wenn das nicht stabil läuft, kannst Du es nichtmal für backups o.ä. einsetzen. Insgesamt ist es von hier schwer zu sagen und, wie schon geschrieben, sind USB-Verbindugen immer ein Risiko. Was genau ist Dein Anwendungsfall? Du hast einen i5-7500, also 4C/4T, mit 8GB RAM (immerhin schon DDR4 möglich - was im Elitedesk drin ist, weiss ich nicht) und 3x 8TB Disks, 2xSSD für Cache ...der unraid Stick sieht auch nach einem komischen No-Name aus, oder? Preiswert ist relativ, aber ein vergleichbares System sollte schon günstiger und sparsamer zu bauen sein...oder was Gebrauchtes (Workstation/Server mit mehr Platz von HP, Fujitsu, o.ä) .......was wäre denn Dein Budget? Du kanst Deinen Use-Case ja mal hier erzählen und anfragen -> https://forums.unraid.net/forum/105-nasserver-eigenbau-hardware/ Edit: mit sowas kann gut starten und zieht Kreise um den i5: https://geizhals.de/wishlists/2960302

...das gefällt mir auch nicht: ...Der Syslog ist voll davon, für Disk1 und Disk2 ...das sind die beiden aus dem 2bay Gehäuse.

Das ist der Parity aber egal, ob die Blöcke alle NULL sind....die hat kein Dateisystem und es macht keinen Unterschied, ob auf den Daten-Disk(s) was drauf ist oder nicht. Das dauert immer gleich. ...ich finde es unschön...was ist, wenn nach einem Bios Update des USB gehäuses oder des EleDesk da eine andeer ID rauskommt....

OK, dann ist das beim ersten Sync normal. ich bin mal gespannt, wie schnell der läuft....ob 2 Tage reichen genau das ist es, was ich komisch finde.

lass es so wie es ist. Du hast nur einen USB3.1 (5Gb/sec) im Elitedesk....der andere Controller ist nur USB2.0....das macht weniger Sinn, da der nur 480Mbps kann. Allerdings verstehe ich nicht, warum an der Parity das "emulated" icon auftaucht 🤔 Edit: oder läuft gerade der Parity Sync/cceck? Die Toshiba und die WDC sind die beiden "single Disks" im 2-bax Gehäuse? Die Parity / einzelne Externe ist was für eine Disk genau? Da wird bei der Parity nur der Controller angezeigt....komische Sache...sind alle beide, externen Gehäuse mit dem EliteDesk verbunden und haben eine aktive, externe Stromversorgung? ...da stimmt was nicht. Wenn alle Disks angeschlossen sind...stell mal Deine Diagnostics hier rein.

Dann würde ich es tatsächlich so machen, wenn Du unbedingt mit USB "experimentieren" willst: Raid macht keinen Sinn, weil Du die Disks so nie im Notfall in einen Rechner einbauen und mounten kannst. Im Array und als Single weil Du dann - zumindest beim read - die Chancce hast, dass nie alle Disk laufen und Daten über den USB ziehen. Parity wird eh langsam sein. Da Du unraid schon mal gebootet hast..was sagt denn ein "lsusb -tv" (CLI-Terminal - rechts oben im Web-Interface - das ">_" Icon öffnen)? Die Idee wäre die Parity und das 2-Bay Case an getrennte Controller zu hängen...ein Nadelöhr weniger