I'm a little late posting this but as it's not been shared still, see below!

Version 6.12.4 2023-08-31

Blogpost - https://unraid.net/blog/6-12-4

Unraid Docs - https://docs.unraid.net/unraid-os/release-notes/6.12.4/

Unraid 6.12.4 is now available and has a fix for macvlan call traces, introduces a new System Drivers page, and has other bug fixes and improvements.

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.

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 this. Tweak a few settings and your Docker containers, VMs, and WireGuard tunnels should automatically adjust to use them:

• Settings > Network Settings > eth0 > Enable Bridging = No
• 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 (i.e. make sure eth0 is configured for the custom network, not eth1) 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". We attempted to do this automatically, but depending on how things were customized you may need to do it manually.
• If your VMs have 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.

Technical Breakdown​

After upgrading to this release, if bridging remains enabled on eth0, 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.

New System Drivers page​

Navigate to Tools > System Drivers for visibility into the drivers available/in use on your system. 3rd party drivers installed by plugins (such as NVIDIA and Realtek) have an icon that links to the support page for that driver. You can also now add/modify/delete the modeprobe.d config file for any driver without having to find that file on your flash drive.

Other Bug Fixes and Improvements​

• This release resolves corner cases in networking, Libvirt, Docker, WireGuard, NTP, NGINX, NFS, and RPC. It includes improving the VM Manager to retain the VNC password during an update.
• The shutdown process was modified to allow the NUT plugin to properly shut the system down.
• The notification display time before auto-closing is now configurable (see Settings > Notification Settings).
• A small change is that packages in /boot/extra are now treated more like packages installed by plugins, and the installation is logged to syslog rather than to the console.
• The Update OS process will automatically update the Plugin-Update-Helper script if necessary.

Anyone else having issues updating settings or profile? Pressing save doesn't do anything, but works fine on other instances for me.

Curious if there is a specific update schedule when the site goes down for maintenance/when the latest releases are loaded or if it's ad-hoc?