sonic6

Which Container are you using?

it wasn't intel-gpu-top, it was the latest Plex update. if you are using the LSIO container, try v1.32.5.7349-8f4248874 which worked fine. this problem isn't the web client, it is the latest update. if you are using any other clients or platforms and using the HDR tonemapping, it won't use hardware transcoding: Source:

also the fix common problem plugin reported nearly every trace as a "mac macvlan trace". don't know if that is fixed.

you are right, the first try is the change to ipvlan, but of your hardware need a seperated MAC-Address per device, or had other conflicts with ipvlan, then use "eth0". (i am using a fritzbox, which needs seperated MAC-Addresses per device). with your hardware i would strait go to the "eth0" solution. yes, i would do that. read carefully the changelog. in short: stop docker, disable array autostart, update unraid, reboot unraid, disable bridging in network settings, activate "host access" in docker settings, start docker, check if all br0 container are started. if not all container started, check if they changed from br0 to eth0. if some container disapeared go to "add container" on docker page, choose your template. change from br0 to bridge, start the container, edit the container again and change it to eth0. after all runs activate the array autostart again. now you should check you router etc, because the MAC-Addresses of your container could be change, also there is a second MAC-Address with the same IP address like your unraid host. this is normal.

@JorgeB @bonienl maybe NOW is the time, to mark this as "deprected" as a fix for MACVLAN? Maybe unipin it, and edition the first Post with a hint to update to 6.12.4 instead of using two NICs? There a still users, who are confused by this """"solution"""

try the simplest solution now: read the 6.12.4 changelog, to the manually steps, update to 6.4.12 and use eth0 instead of br0.

@scolcipitato is there a way to see the correct startup order for the docker container? if i remember right it is the position, but without the folders? How can i set up my wished startup order?

Gibt im Container Terminal danach testweise mal "ip address" ein, dann sollte dir die IP Adressen des Containers aufgelistet werden. Kleiner Tipp am Rande: deaktiviere den DHCPv6 und lass die Adresszuweisung per SLAAC stattfinden.

Du kannst dir auch n Loch ins Knie bohren und Maggie reinkippen, würde das aber trotzdem keinem dritten hier empfehlen... Du kannst ULA sehr wohl beeinflussen. Das prefix wird per SLAAC oder DHCPv6 vom Router vorgeben und die MAC kommt von der Hardware. Alles andere ist eine Frage des routings und was man konfiguriert. Mein Pihole läuft als LXC Container problemlos per ipv4/6 im LAN. Sogar innerhalb eines Docker User Network läuft IPv6. Selbst anfragen die über den CF-Tunnel kommen, funktionieren.

LLA ist aber nicht für Nutzdaten bestimmt und nicht für das Routen in andere Netze bestimmt, dafür gibt es ULA. Das statische Präfix bekommst du über die ULA, das wechselnde Präfix der GUA erledigt man über ein DDNS Script. Man kann einem Gerät ja auch ohne weiteres mehere IPv4/IPv6 Adressen mitgeben. Wo ist also das Problem? Da es hier um (wie ich Anfangs überlesen hatte) eine "lokale" Verfügbarkeit des Container geht, einfach MACVLAN mit eth0 nutzen und dem Container eine ULA zuteilen. Ggf. wie @KluthR schon schrieb eine feste MAC vergeben (was bisher bei mir noch nicht nötig war). Die Krux ist hier lediglich, dass die automatische Routing Tabelle in Unraid noch wild zwischen ULA und GUA wechselt. Daher kann ich IPv6 mit Docker Containern bisher nur per eth0 (früher br0) stabil realisieren.

Ich möchte dein Arbeit in keiner weise schmälern, jedoch ist es wichtig hier für Klarheit im MACVLAN Chaos und den damit verbundenen Vermutungen zu schaffen. Das ist Richtig, weil man MACVLAN nicht und nie und niemals zusammen mit einer Bridge nutzen darf. (Warum das in der Vergangenheit gemacht wurde, lassen wir mal dahin gestellt. Auch warum es immer noch möglich ist, finde ich fragwürdig.) Irgendwo im Englischen Bereich gab es hierzu Informationen von den Dev's (Unraid und Kernel), dass man MACVLAN nicht mit einer Bridge betreiben sollte. Das war auch der Grund, warum vor Monaten schon IPVLAN als Default Driver für Docker eingeführt wurde. Die Lösung die mit 6.12.4 eingeführt wurde, dass man eth0 mit MACVLAN nutzen kann, war lediglich für user gedacht, die aufgrund ihrer Hardware auf MACVLAN angewiesen waren. (Zb die Fritzbox, die mehrere IP Adresse von einer MAC nicht mag.) Für alle anderen gilt im ersten Schritt: Auf IPVLAN umstellen. Das eine Bridge nicht mehr mit MACVLAN zu betreiben ist, steht im Changelog recht detailliert, auch was hierfür zutun ist um unter MACVLAN auf eth0 umzustellen.

fall dein Server auf 6.12.4 läuft, könnte es eher an 6.4.12 liegen, dass es keine probleme mehr mit macvlan gibt. Für alle anderen, die aufgrund von den MACVLAN Traces hier gelandet sind: Ließt den 6.12.4 Changelog, geht die manuellen Schritte durch und updated, danach sind die MACVLAN Probleme Geschichte. Für alle anderen Fälle, danke natürlich für deinen Aufwand.

hi, today i tried mounting an HDD via temrinal with: /usr/local/sbin/rc.unassigned mount /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K0VZ4TVK sleep 30s but the drive wan't moutable: Sep 4 06:43:13 Unraid-1 emhttpd: cmd: /usr/local/emhttp/plugins/user.scripts/startScript.sh /tmp/user.scripts/tmpScripts/Backup-to-UD/script Sep 4 06:43:14 Unraid-1 unassigned.devices: Mounting partition 'sdd1' at mountpoint '/mnt/disks/WD-WCC7K0VZ4TVK'... Sep 4 06:43:14 Unraid-1 unassigned.devices: Mount cmd: /sbin/mount -t 'xfs' -o rw,noatime,nodiratime '/dev/sdd1' '/mnt/disks/WD-WCC7K0VZ4TVK' Sep 4 06:43:21 Unraid-1 kernel: XFS (sdd1): Mounting V5 Filesystem Sep 4 06:43:21 Unraid-1 kernel: XFS (sdd1): log mount failed Sep 4 06:43:21 Unraid-1 emhttpd: read SMART /dev/sdd late i tried mounting with the GUI Button and that worked well. i unmounted the drive and tried again the terminal and that also worked now. i report this just for the case. diag is attached. unraid-1-diagnostics-20230904-0719.zip

Hm, i did test it again and it works well... I am using an unmounted UD as destination and mount es with: /usr/local/sbin/rc.unassigned mount /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K0VZ4TVK sleep 30s Maybe be the drive wasn't mouinted correctly? Can you add a "check" if the destination ist available?

das Prefix wird sich dennoch weiterhin ändern. sollte kein problem sein, das Prefix verhält sich wie deine IPv4... sie ändert sich. Also gehst du wie bei IPv4 vor und erstellst eine DDNS auf die IPv6 des Container (nicht vom Host).