jj1987

Nein, "0.0.0.0" heißt "alles" Wenn du hingegen nur 192.168.0.0/24 einträgst, werden nur Ziel-IPs aus diesem Segment über den Wireguard Tunnel geschickt. Also genau so wie du es möchtest.

Sorry, ja Bridge muss aus

Sobald Bonding aus ist, wird die Option zwischen macvlan und ipvlan wählen zu können deaktiviert. Es ist dann automatisch macvlan aktiv. Bin mir nicht sicher ob das irgendwann nach 6.12.4 kam oder ob ich da tatsächlich einen Fehler beim Schreiben der Anleitung eingebaut habe🤔

Also bei Wireguard ganz allgemein (kenne/nutze die UNRAID Umsetzung nicht) kann man das jeweils beim Client regeln über die "allowed IPs": Wenn dort die "0.0.0.0/0" drin steht geht jeder Traffic durch den Tunnel. Also das einfach rausnehmen und es sollte nur noch der "interne" Traffic durch den Tunnel gehen

Da könntest du bei MSI aber Pech haben. Zumindest früher waren die da leider nicht gerade weit vorne. Aber wie gesagt "früher". Hab schon ewig kein MSI Board mehr selbst in den Händen gehabt, mag also sein dass sich da inzwischen etwas zum positiven geändert hat

Gar nicht... Daher am besten nicht per /dev/sde mounten sondern per /dev/by-id. Die sollte immer gleich bleiben

Ist zwar irgendwie Off topic, aber bevor das hier unkommentiert stehen bleibt: Ganz im Gegenteil. Bei Fritzboxen sollte unbedingt macvlan genutzt werden. Aufgrund eines Fehlers in der Docker-internen Bridge muss man aber einige extra Einstellungen in UNRAID vornehmen. Daher auch der Sticky thread im Anleitungen Subforum

? Du brauchst doch keine VM um die IGPU im Docker nutzen zu können Und gvt-g braucht man nur um die IGPU in VM UND Docker nutzen zu können. Und wenn du sowieso zusätzlich noch ne Arc hast brauchst du das doch gar nicht?!

Sind die Disks im spin down? Wie sehen die c-states aus?

Läuft Plex bei dir in einer VM?! Ein Docker wäre da Ressourcenschonender. Jeweils ein rebbot dazwischen?

Fast Boot aktiviert? Das erzeugt gerne solche Probleme Ggfs also deaktivieren

Jein, man muss schon selbst aktiv werden. Hierzu die angepinnte Anleitung im Anleitungen Subforum anschauen

Mir wäre bislang noch keine erfolgreiche Umsetzung bekannt. AMD ist da (leider) noch nicht soweit

Über das Plugin "Appdata Backup" kann man auch den USB Stick sichern. Und wenn Daten einfach so vom Stick verschwinden, gibt es effektiv ja nur zwei Möglichkeiten: 1) gelöscht (vom User oder eher unwahrscheinlich Malware) 2) der Stick steigt langsam aus So oder so ein Backup schadet nie

Also mir ist bislang noch keine externe SSD untergekommen die günstigster als eine gleich gute/schnelle interne SSD war. Lohnt sich also nicht. HDD shucken ist ja inzwischen auch nicht mehr interessant

Das ist schon ziemlich optimistisch. In dem Bereich liegen idr Micro PCs ala Lenovo Tiny. Ein Selbstbau in der Region wird schon herausfordernd, denn dafür muss alles passen, gutes Netzteil, saubere Implementierung der Energiesparmodi in sämtlichen(!) Komponenten, etc. Mit nem N100 vielleicht schon etwas leichter, da wurde aber wenn ich mich Recht entsinne eher das AsRock empfohlen.

Pro (funktionierender) Parity HDD ist eine Daten HDD gesicher. Geht die einzige Parity futsch darf keine Datendisk Fehler haben. Ist bei einer Parity Disk bereits eine Datendisk ausgefallen, darf keine weitere ausfallen. ABER: selbst wenn doch sind die Daten der noch funktionieren Disks (extern) noch auslesbar. Man verliert im worst Case nur die Daten der defekten Disk(s) Schreibend (direkt aufs Array ohne Cache) ca 1/2 - 1/3 der max Geschwindigkeit der Datendisk. Idr also zwischen 60-90 MB/s Lesend halt die Geschwindigkeit der jeweiligen disk

Gibt es, muss aber erst in den mover Einstellungen aktiviert werden

Was hat denn das eine mit dem anderen zu tun? Heißt das du hast gar keinen Cache mehr? Unter settings-> Docker aktivieren. Kann sein dass das Image neu erstellt werden muss, da du ja offensichtlich irgendwas mit dem Cache gemacht hast. Ist aber nicht weiter schlimm. Du musst dann nur unter apps-> previously installed deine Docker wieder installieren (keine sorge, Daten und Einstellungen bleiben erhalten. Nur das eigentliche Container Image muss wieder installiert werden) Dann synchronisiere sie doch?! Dann verschwindet auch der Fehler

Nein, denn so ein Paket soll den Server starten, keine HDDs. Vielleicht könnte man sich irgendwas basteln, dass kontinuierlich nach Magic Pakets scannt und dann im Falle des Falles ein spinup veranlasst. Aber das ist offensichtlich nicht mal eben so getan

Wie kommst du denn auf das schmale Brett? Das sind normale Single Devices. Wie sollte da ein RAID5 entstehen - ohne UNRAID Parity? Oder hast du das extremst verkürzt geschrieben und meinst eigentlich er soll die in einen Pool schmeißen und das dann als zfs raidz1 laufen lassen?!

Wenn es dumme/passive Karten sind, sollte da eigentlich gar nichts passieren. Da werden dann tatsächlich einfach nur die vorhandenen lanes physisch aufgeteilt. Bei aktiven Karten mit pcie Switch drauf, da könnte ich mir das durchaus vorstellen

Sofern sie korrekte Unique(!)UID haben, funktionieren auch zwei gleiche NVME. Habe ich ja auch bei mir im System.

Nein UNRAID geht über UUID. Und "dank" des USB Gehäuses das zwischen UNRAID und den NVME steckt wird die UUID anscheinend nicht korrekt weitergegeben, nach deiner Fehlerbeschreibung scheinen alle angeschlossenen Geräte dieselbe zu bekommen, da ja auch die Parity "verschwindet". Genau genommen ist also dein USB Gehäuse das Problem. Und eben weil dies sehr häufig vorkommt wird hier (im Gegensatz zu diversen selbsternannten YouTube Sternchen) ausdrücklich von solchen Konstrukten abgeraten. Denn am Ende kommt bei den enttäuschten Usern dann das Fazit: Was so verkürzt halt schlicht nicht stimmt

Da hast du den Fehler... USB hat im Array und Pool nichts zu suchen und führt regelmäßig zu genau diesen Problemen