MAM59

Turn on FLOW CONTROL on BOTH sides! Your Unraid is set to "Receive only", your Switch to "none". This will very likely end up in lost packets, timeouts and retransmissions.

usually drops at 10G mean: BAD CABLE!!! Make sure, you have got a real 10G cable. Most of them sadly are are "raw cables" which means, the cable is fine, but the plugs are not capable of 10G. As a last resort the speed will drop to 5 or even 2,5 G to compensate the transmission errors. BTW: it has NOTHING to do with power efficence. The link speed is the same for 2.5, 5 and 10G. Just the Usage/Pause times are different. So it is not wrong or uncommon, that a switch reports a 10G link while the real used speed is lower. Make sure that Flow Control is turned on and working, else you will notice a lot of retransmissions and slowdowns. BTW2: if possible, avoid twisted pair 10G completly and go safe with fiber or direct connect SFP+ BTW3: you HAVE a 10G connection, read your list correctly! the 10000 comes before 2500 and 5000. And this is just an offered list, the picked speed is 10000 as you can see below.

implziert ja das TS mit NPM läuft (was ja wohl nicht der Fall ist) NPM erlaubt auch Streams zu forwarden, aber ob das mit diesem Teamspeak funktioniert, wage ich etwas zu bezweifeln. Grundsätzlich gilt aber, dass NPM im Host Modus betrieben werden MUSS, damit V6 Adressen durchgereicht werden können. Streams mit NPM habe ich nie ausprobiert. (Hier ist streamfreie Zone :-))) )

my guess (can't proove it) is that they have artificially slowed it down in the binary. It does not honor the "-i" (interval) option too. Normally this would default to 1 s. But it seems it always sleeps at least 3 seconds between packets. If you try the "-f" (flood ping) option, you see it can do much much faster. So I think "this is wanted" by limetech (no idea what it should be good for, also the sleep comes BEFORE the first packet, not AFTER as it should) Anyway, you can consider it harmless. Nothing wrong with your network connection.

What VARIABLES ? ? ? You used "automatic" for the interface (which is totally correct!). This means, all fields are filled out automatically. No PART1 or PART2! The messages come from "dhcpd", this is not installed by default, and also not needed for V6 operations. It conflicts with the router's announcements (fields are doubled, usually creates a mess). So you better uninstall dhcpd fast, this will also get you rid of the messages.

Thou shalt never bond cards with different speeds (only "active backup" would be a valid bonding choice for this combination) but with lacking diagnostics its hard to tell anything more.

Zur Zeit der Erstellung des Tutorials war das auch so. Da konnten Docker noch gar kein V6

Nein, der ist fest und tief in der Docker Runtime vergraben. Docker ist bei IPV6 noch eine ziemliche Diaspora. Die jetzige "Lösung" ist nur ein "geht so" Patch. Noch weit von richtiger Implementation entfernt. Beim Dockerdesign wurde das gar nicht mit beachtet und nur halbherzig später draufgepfropt. IPV6 und NAT, da schaudert es mich...

Der Fehler liegt bei Dir. Du hast den NPM nicht im HOST Modus angebunden, somit bekommt er nur ge-nattete V6 Adressen (eben diese fd17::1). Konfiguriere den NPM Docker um auf Host, dann kommen auch die "richtigen" Adressen durch. WARNUNG: NPM MUSS auf den Ports 80 und 443 laufen. Die sind normalerweise von der UNRAID GUI belegt. Diese musst Du VORHER auf andere Ports umkonfigurieren (Einstellungen->Verwaltung). Warnung 2: es kann sein, dass die derzeitigen Zertifikate durch die Umstellung ungültig werden oder Proxy Hosts nicht mehr funktionieren. Im schlimmsten Fall musst Du alle löschen und neu in NPM einrichten. Mach Dir also ne Liste, damit Du keinen vergisst. Warnung 3: manche Versionen von NPM funktionieren nicht im HOST Modus. Ich war es irgendwann leid mit dem Leid und date NPM schon ewig nicht mehr ab. Die Version jc21/nginx-proxy-manager:2.9.22 funktioniert einwandfrei, keine Ahnung was die danach rumgebastelt haben und es damit verbockt haben. Ich bleib bei 2.9.22.

So, just give it a try like @Kilrah says and be prepared that it does not work. So you have to take the longer way that @itimpi describes (which will need a 2nd free disk to be formatted and copied on later)

As long as there is no parity disk, you can assign ANY full disk to an unraid array. It just will be used (unless the filesystem can be read by UNRAID, which is very likely) and shares will be created for all top level directories automatically. Even IF there is a parity already, you can do this if you turn off parity first, add the disk then reassign parity (will be rebuild afterwards). UNRAID runs from an USB stick, the NVME is not used then (you may assign it as a cache drive, but it will be formatted then). But of course, it is always clever to have a backup of the data somewhere... And as long there is no parity drive in UNRAID, there is no data protection at all (even WITH parity this is no reason for NOT having a backup!)

Na ja, ich vermute, da kamen sich Du und der Mover in die Quere. Der Mover sammelt erstmal seine ganzen Aufgaben ein und fängt erst danach an zu verschieben. Wenn Du gleichzeitig die Dateien von Hand verschoben hast, dann konnte er sie nicht mehr finden.

Das hast Du vorher aber nicht so gesagt... Prinzipiell ist da nix falsch dran, allerdings wäre mir das aber zu manuell und kompliziert. Hier geht der Backupserver einmal am Tag mittels WLAN Steckdose an, fährt hoch, kopiert per rsync oder robocopy übers LAN die neuen und geänderten Dateien rüber und schaltet sich dann wieder total ab. Dein Problem liegt darin, dass Du versuchst ALLES zu kopieren, was aber nicht funktionieren kann, denn einige dieser "Dateien" sind keine, sondern spezielle Dinge wie Sockets, Pipes und Devices. Und die haben nun mal kein Ende, da kannst Du ewig kopieren. Du must also dafür sorgen, dass einige Sachen nicht mitkopiert werden, schon der Versuch ist strafbar, wie Du siehst. Also geh mal alle zu kopierenden Verzeichnisse durch und finde alles, was nicht nach "normaler" Datei aussieht. Also etwas sowas: drwxr-xr-x 2 root root 60 Jan 28 18:09 vfio/ crw------- 1 root root 10, 127 Jan 28 18:10 vga_arbiter crw------- 1 root root 10, 137 Jan 28 18:09 vhci crw-rw---- 1 root users 10, 238 Jan 28 18:11 vhost-net prw-r----- 1 root root 0 Jan 28 18:10 xconsole| Bei Deinem speziellen Hänger vermute ich, dass die Berechtigungen mit "p" anfangen, es also eine Pipe ist.

Klingt ausgesprochen fragwürdig und abenteuerlich... wie gesagt, sockets und pipes solltest Du bei der Kopie ausklammern und beim Backup Share den Cache abklemmen. Hilft ja eh nix, da Du vor dem Abklemmen eh auf den Mover warten musst. Ist also keine Zeitersparnis den Umweg über den Cache & Mover zu nehmen.

erstmal skript stoppen, dann sollte der mover von alleine zuende laufen. Ansonsten, shell öffnen, "mover stop" machen und in sich gehen. Wieso sicherst Du in den Cache, statt direkt auf die USB Platte? ausserdem liest sich "dbgpipe.log" wie ein unix domain socket. Der hat kein "Ende" und man kann ihn durch Kopie gar nicht sichern. Du solltest also solche Pipes und Sockets vom Backup ausklammern.

ja. iss klaaah.. DU bist im Weg. Der Mover wartet, bis Zoneminder mal fertig ist. Also stoppe mal alle Docker, dann wird er zu Potte kommen. Und danach überleg Dir, ob es so sinnvoll ist, inkrementelle Backups auf den Cache legen zu wollen. (während Dateien offen sind, kann er sie nicht verschieben. also wartet er. Manchmal eben auf Godot...)

unfortunatly, "same size" is often not "same size" 😞 For different interfaces, the partition layout may be different. Some start at sector 64, some already at sector 1 and some somewhere else. So even if you are using disks with the same number of sectors, the "net free value" maybe different. Sadly, this cannot be known before. But it seems that your former USB interface has used a different drive layout.

Keine Ahnung, ich benutze diese Docker nicht. Ich hab den DHCP Server auf einem FBSD Server "richtig" installiert. Für solche Basisdienste wären mir wackelige Docker viel zu risikoreich (Docker laufen ja erst gaaaanz zum Schluß nach dem Booten, da kann es dann schon Henne&Ei Probleme geben). Ansonsten findest Du die erforderlichen Config Änderungen für ISC z.B. unter https://askubuntu.com/questions/874648/setting-options-66-and-67-for-isc-dhcp-server Generell sieht das so aus: #option 66 option tftp-server-name "w.x.y.z"; #option 67 option bootfile-name "test.cfg"; aber wie gesagt, den TFTP Server und das richtige Bootfile musst Du auch installieren... Da fehlt also noch Einiges... Auch must Du dafür sorgen, dass jede Kiste ihr RICHTIGES Bootfile zugewiesen bekommt. IP-Phones können meist nix mit Windows 11 anfagen und PCs lieben keine Cisco Betriebssysteme. Bei ISC macht man das so, dass man verschiedene "Klassen" einrichtet, meist werden diese durch die Mac Adressen definiert. Beispiel: class "raspi" { match if substring(hardware,1,2) = b8:27 or substring(hardware,1,3) = dc:a6:32 or substring(hardware,1,3) = da:0b:06; option host-name = concat("raspi-",binary-to-ascii (16, 8, "", substring (hardware, 1, 6))); ddns-hostname = concat("raspi-",binary-to-ascii (16, 8, "", substring (hardware, 1, 6))); ddns-domainname= "media.XXXX.de"; deny client-updates; #ignore client-updates; update-static-leases on; use-host-decl-names on; # log (info,concat("gefunden Raspi ",ddns-hostname)); } Hier werden z.B drei verschiedene Bereiche von MAC Adressen erkannt und Raspberrys zugewiesen. Aus den Mac Adressen wird dann ein Hostname wie "Raspi-YYYYYY.media.XXXX.de" gebildet. Der wird dem Raspi mitgeteilt und auch im lokalen DNS Server registriert. Hier könnte man dann ein spezielles Bootfile hinterlegen, das nur für Raspis gilt. (wobei das Beispiel hinkt, die verschiedenen Raspis brauchen auch andere Bootfiles, wahrscheinlich muss man für jeden MAC Bereich deshalb eine eigene Klasse definieren) Ich hab hier so 20 Klassen und noch etwa 50 Hosts mit speziellen Einträgen. Die Konfigdatei ist deshalb recht lang, aber das Meiste is Cut&Paste. Grundsätzlich oben die Options für alle setzen, dann Klassen/Hosts definieren und darin einzelne Options überschreiben oder ergänzen. Ist recht simpel.

Das "Besondere" sind spezielle Records (66 und 67) für PXE bzw TFTP, die man diesen Servern nicht beibringen kann. Es gibt allerdings die Möglichkeit, mit "ProxyDHCP" die fehlenden Options dem vorhandenen Server "unterzujubeln" und somit die Antwort zu ergänzen. Ausserdem muss man natürlich auch noch einen TFTP Server aufsetzen, der auf Anforderung dann das richtige Betriebssystem anbietet und hochlädt. (Betonung auf "RICHTIGE!", der Server muss erkennen, WER da anfragt und dann die richtige Datei liefern) Für Details hier lesen: https://wiki.openthinclient.org/omd20212/openthinclient-management-server/proxydhcp-pxe-konfiguration oder https://www.netz-weise-it.training/weisheiten/dhcp-proxy-wds-server-dhcp-option-60-66-und-67-und-was-das-mit-pxe-boot-zu-tun-hat.html Allerdings gibt es auch reichlich DHCP Server auf dem Markt (zb. ISC-DHCPD, oder Microsoft DHCP Server), die man um die nötigen Einträge ergänzen kann, auch wenn die GUI da etwas im Weg steht.

your mistake is that you have assigned a gateway to every card. Unless you have really 3 seperate internect connections, this is wrong. Only the "real" card (which contains the router to the internet) should have the router's address stored as "default gateway". There are implicit automatically generated routes to the other card's nets. You need to add these routes to other machines and your default router to make them accessible from inside and outside (if wanted)

as usual I should add the warning "Do not use ZFS in the UNRAID array" (at least not now). There are serious problems with speed, they are investigating, but unless it is fixed, zfs is an absolute NO-GO (but can be used for pools). If you dare to move the array be prepared to move it back soon again. (you will find a lot of threads here if you search)

No need for somebody to write one. You have one already if you install the "unassigned devices" plugin. With it you can mount (and even publish) ISO files. Even permanently if wanted.

There is likely a misconfiguration, machine and gateway need to be on the same net unless you are using specific netmasks. Check your addresses and routing tables.

This is not really DHCPV6. What happens is that docker reads the hosts V6 address (here from SLAAC, in my net it is static), strips the first 64 bit and takes it as the prefix (which is wrong here, i have /48 not /64, but it still works because it carries over the next block too). Copies the received gateway address, which means, your <prefix>::1 must be announced somewhere. It then uses some dice throws to generate a new 16bit section, here 2000, and then appends it to the prefix. This new "prefix" is offered by router advertisement protocol to the starting dockers with a netmask of /72. The dockers then pick their own address from this pool by SLAAC The gateway is somehow a guess because if not static, it is announced as the link local FE80:: adress by the real router. This cannot be used for the docker subnet, therefor it makes an "educated guess" what the real, routeable, address could be. In your case it picks the ::1, which is wrong as you say. I use static addresses, and also use the "real" address for the gateway. Thats why it works here. Sad news for you: the Fritzbox handles V6 very poorly and utterly wrong. It will be hard to impossible to train it it use a "good" address, switching the dockers to static wont help you because your prefix is dynamic... BAD LUCK!!! Maybe your prefix changes are less frequent (my nephew for instance has one or two changes per year), then it might be worth to change it manually each time. But with a daily change you are really lost. Try to fix the FB to the ::1 address, this would work best. (but if the prefix changes, you always need to restart the dockers)

Nö, das ist so und es ist auch kein Mysterium. Die Parity speichert einfach die Summe aller gleichen Sektoren von allen Platten (ist eine Platte "zu ende" wird sie eben nicht mehr mit aufsummiert bzw liefert einen sektor voller Nullen). Geht eine Disk kapput, kann man einfach die anderen wieder aufsummieren und vom Parity Sektor subtrahieren. Übrig bleibt dann der fehlende Datensektor. Einfach, aber genial. (So ähnlich wie RAID 5, nur das da die Platten nur bis zum höchsten Sektor der kleinsten Platte verwendet werden. Der UNRAID Trick ist einfach, stattdessen Null zu liefern) Für etwas mehr paranoide Zeitgenossen kann man auch eine zweite Parity Platte hinzufügen, aber den Bedarf hatte ich noch nie. Als "Haken" der Sache ergibt sich eben der Zwang, dass die Parity Disk die "größte von allen" sein muß. Sie muss eben Sektoren mit Nummern zur Verfügung stellen, die jeden Sektor jeder anderen Platte aufnehmen kann. Ist eigentlich auch einfach verständlich wenn man mal drüber nachdenkt. Also, kein Elektrik-Trick oder Gottes-Hand. Nur simple Addition und Subtraktion. (oder XOR, keine Ahnung, ist aber auch egal, irgendeine reversible Rechenoperation ohne Carry)