NAS-Man

7.3.0 -> 7.3.1 update was smooth as silk. Appreciated, thank you!

7.3.0-rc.2 ---> 7.3.0 Stable went smoothly. Thank you!

Updated from 7.2.5 ---> 7.3.0-rc.2 booted back up no issues & system seems OK. Updated early to get the 7.3 kernel contains the fix for CVE-2026-31431, the Copy Fail local privilege escalation vulnerability for peace of mind security. Will report back if any issues arise. Thank you

Updated 7.2.4 ---> 7.2.5 Successfully with no issues. Thank you for your hard work, I appreciate all of you!

Upgraded 7.2.3 -> 7.2.4 no issues. Thank you Unraid team for your continued hard work, you all are appreciated very much!

Welcome to the Unraid team @SimonF 😁

7.2.2-> 7.2.3 no issues. Thank you

Welcome to the Unraid team @ChristianUnraid

RIP bonienl My condolences

Updated 7.2.0 --> 7.2.1 no issues. Thank you

Updated 7.1.4 --> 7.2.0 no issues. Thank you for your hard work on this release, I appreciate all of you!

Welcome to the UNRAID family Chris! @TidalBuzz

Updated from 7.0.1 with no issues

Upgraded 6.12.13 -> 6.12.14 reboot froze but after powering off then back on it booted fine. So far no noticeable issues, thanks for the update.

Upgraded from 6.12.11 -> 6.12.13 no issues. Thank you

Updated 6.12.10 -> 6.12.11 no issues. Thank you for the update!

Looks Great!

Welcome to the Unraid family Nick!

Updated from 6.12.9 --> 6.12.10 no issues. Thank you

Updated from 6.12.8 --> 6.12.9 no issues. Thank you so much for your hard work, I sincerely appreciate all of you!

Upgraded from 6.12.6 to 6.12.8 without issue. Thank you, I appreciate your hard work!

Updated from 6.12.5 -> 6.12.6 no issues. Thanks again for your hard work & quick fix.

6.12.4 -> 6.12.5 no issues. Thank you

Welcome to the UNRAID family @Adam-M

Run Tools > Update Assistant first then follow release notes upgrade procedure: Version 6.12.4 2023-08-31 Upgrade notes Known issues Please see the 6.12.0 release notes for general known issues. Rolling back Before rolling back to an earlier version, it is important to ensure Bridging is enabled: Settings > Network Settings > eth0 > Enable Bridging = Yes Then Start the array (along with the Docker and VM services) to update your Docker containers, VMs, and WireGuard tunnels back to their previous settings which should work in older releases. Once in the older version, confirm these settings are correct for your setup: Settings > Docker > Host access to custom networks Settings > Docker > Docker custom network type If rolling back earlier than 6.12.0, also see the 6.12.0 release notes. Fix for macvlan call traces The big news in this release is that we have resolved issues related to macvlan call traces and crashes! The root of the problem is that macvlan used for custom Docker networks is unreliable when the parent interface is a bridge (like br0), it works best on a physical interface (like eth0) or a bond (like bond0). We believe this to be a longstanding kernel issue and have posted a bug report. If you are getting call traces related to macvlan, as a first step we recommend navigating to Settings > Docker, switch to advanced view, and change the "Docker custom network type" from macvlan to ipvlan. This is the default configuration that Unraid has shipped with since version 6.11.5 and should work for most systems. If you are happy with this setting, then you are done! You will have no more call traces related to macvlan and can skip ahead to the next section. However, some users have reported issues with port forwarding from certain routers (Fritzbox) and reduced functionality with advanced network management tools (Ubiquity) when in ipvlan mode. For those users, we have a new method that reworks networking to avoid issues with macvlan. Tweak a few settings and your Docker containers, VMs, and WireGuard tunnels should automatically adjust to use them: Settings > Network Settings > eth0 > Enable Bonding = Yes or No, either work with this solution Settings > Network Settings > eth0 > Enable Bridging = No (this will automatically enable macvlan) Settings > Docker > Host access to custom networks = Enabled Note: if you previously used the 2-nic docker segmentation method, you will also want to revert that: Settings > Docker > custom network on interface eth0 or bond0 (i.e. make sure eth0/bond0 is configured for the custom network, not eth1/bond1) When you Start the array, the host, VMs, and Docker containers will all be able to communicate, and there should be no more call traces! Troubleshooting If your Docker containers with custom IPs are not starting, edit them and change the "Network type" to "Custom: eth0" or "Custom: bond0". We attempted to do this automatically, but depending on how things were customized you may need to do it manually. If your VMs are having network issues, edit them and set the Network Source to "vhost0". Also, ensure there is a MAC address assigned. If your WireGuard tunnels will not start, make a dummy change to each tunnel and save. If you are having issues port forwarding to Docker containers (particularly with a Fritzbox router) delete and recreate the port forward in your router. To get a little more technical... After upgrading to this release, if bridging remains enabled on eth0 then everything works as it used to. You can attempt to work around the call traces by disabling the custom Docker network, or using ipvlan instead of macvlan, or using the 2-nic Docker segmentation method with containers on eth1. Starting with this release, when you disable bridging on eth0 we create a new macvtap network for Docker containers and VMs to use. It has a parent of eth0 instead of br0, which is how we avoid the call traces. A side benefit is that macvtap networks are reported to be faster than bridged networks, so you may see speed improvements when communicating with Docker containers and VMs. FYI: With bridging disabled for the main interface (eth0), then the Docker custom network type will be set to macvlan and hidden unless there are other interfaces on your system that have bridging enabled, in which case the legacy ipvlan option is available. To use the new fix being discussed here you will want to keep that set to macvlan. https://docs.unraid.net/unraid-os/release-notes/6.12.4/#:~:text=This release resolves corner cases,properly shut the system down.