On 4/30/2026 at 10:36 PM, SpencerJ said:

Breaking change: Docker containers may receive a new dynamically generated MAC address each time they are created

Only to get prepared for this breaking change.

Why "may"?

Are there special settings or circumstances causing the "generate of a new dynamic MAC"?

Hello everybody,

after updating from 7.2.4 to 7.2.5 I can't help but feel that the CPU load (or rather the activity judging by the core load graphs in the overview) has gone up. Also the web UI feels slower.

Am I imagining things or does somebody feel the same for his server?

For those experiencing issues with nvidia driver, i downgraded the version to 580.159.03 and after a reboot all seems to work fine

Upgrade forced to production driver which eol 10 series cards. 580 is last Nvidia drivers for Pascal cards

Miffed that the updated forced the driver update...

Stalig dmesg at boot also has Nvidia warning and 3rd party missing applications access

Either install them or don't

22 hours ago, NoRaid99 said:

Only to get prepared for this breaking change.

Why "may"?

Are there special settings or circumstances causing the "generate of a new dynamic MAC"?

I belive in the release notes it says that if you manually assigned a MAC address using the "Exra Parameters" field in the Docker Container UI, that it will automatically carry over. So I think this is why they used "may". In all other circumstances, I beleive your containers will be assigned new, random MAC addresses. I have no idea if they're persistent across reboots.

It also seems like they have different IP assignments, too (though still within the defined subnet).

Edited May 3May 3 by jademonkee
typo

@jademonkee ,thanks a lot for your answer.

I think this makes sense like you explained and hope somebody can confirm, if so.

In v.7.2.4 and before, (in my case - container MAC with active NetworkType: custom: eth0 and specified local IP) , the first generated MAC did persit every reboot and update of the container. This is important for me because DHCP and firewall settings.

So, if I'm right, from now on I do have to:

On 4/30/2026 at 10:36 PM, SpencerJ said:

set a fixed value in the new MAC Address field on the Docker template

This creates a new question, if I stop docker, deactivate auto start and update to 7.4.5, set the new value MAC Adress in the template, will it be possible somehow to keep the old MAC?

30 minutes ago, NoRaid99 said:

This creates a new question, if I stop docker, deactivate auto start and update to 7.4.5, set the new value MAC Adress in the template, will it be possible somehow to keep the old MAC?

If you set the new MAC same as the old one, it should keep it.

I will report back, but do not have the time atm to update. There is to much "important" stuff on that server.

Description:

I recently updated my Unraid server to the latest version, but upon reboot, the system fails to start. The boot process halts with errors indicating that the xHCI host controller is dead, followed by the USB drive disconnecting. Ultimately, it fails to mount the boot partition with the error mount: /boot: special device /dev/sdc1 does not exist.

Troubleshooting Steps I've Taken:

1. Changed USB Ports: I tried plugging the boot USB into different ports (both USB 2.0 and USB 3.0), but the exact same error persists.

2. Checked USB Health on Windows: I plugged the USB flash drive into my Windows PC. The drive is fully recognized, and I can read and write files without any access denial or errors. It does not seem to be a physical hardware failure of the USB drive itself.

It seems like there is a kernel/driver conflict with the USB controller occurring during the boot process after this recent update.

System Information:

• Previous Unraid Version: 7.2.4

• Updated Unraid Version: 7.2.5

• Motherboard: ASUS PRIME B550M-A

• CPU: Ryzen 4650G

• RAM: DDR4 Samsung 32G*2 + 16G*2

• USB Drive: Samsung 64GB

Error Log on Screen:

Checking /dev/sdc1 ...
xhci_hcd 0000:01:00.0: Abort failed to stop command ring: -110
xhci_hcd 0000:01:00.0: xHCI host controller not responding, assume dead
xhci_hcd 0000:01:00.0: HC died; cleaning up
xhci_hcd 0000:01:00.0: Timeout while waiting for setup device command
clocksource: Long readout interval, skipping watchdog check: cs_nsec: 5566066279 wd_nsec: 5566038769
usb 2-1: USB disconnect, device number 0
usb 2-1: device not accepting address 2, error -22
sd 7:0:0:0: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=DRIVER_OK cmd_age=46s
sd 7:0:0:0: [sdc] tag#0 CDB: opcode=0x28 28 00 01 63 9b a0 00 00 40 00
I/O error, dev sdc, sector 23305120 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
sd 7:0:0:0: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=DRIVER_OK cmd_age=0s
sd 7:0:0:0: [sdc] tag#0 CDB: opcode=0x28 28 00 01 63 9b e0 00 00 80 00
I/O error, dev sdc, sector 23305184 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
device offline error, dev sdc, sector 23305120 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Buffer I/O error on dev sdc1, logical block 23303072, async page read
device offline error, dev sdc, sector 23305121 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Buffer I/O error on dev sdc1, logical block 23303073, async page read
device offline error, dev sdc, sector 23305122 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Buffer I/O error on dev sdc1, logical block 23303074, async page read
device offline error, dev sdc, sector 23305123 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Buffer I/O error on dev sdc1, logical block 23303075, async page read
device offline error, dev sdc, sector 23305124 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Buffer I/O error on dev sdc1, logical block 23303076, async page read
device offline error, dev sdc, sector 23305125 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Buffer I/O error on dev sdc1, logical block 23303077, async page read
device offline error, dev sdc, sector 23305126 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Buffer I/O error on dev sdc1, logical block 23303078, async page read
device offline error, dev sdc, sector 23305127 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Buffer I/O error on dev sdc1, logical block 23303079, async page read
fsck.fat 4.2 (2021-01-31)
/dev/sdc1: Can't lookup blockdev
mount: /boot: special device /dev/sdc1 does not exist.
       dmesg(1) may have more information after failed mount system call.
umount: /dev: target is busy.
umount: /: not mounted.
cannot mount /dev/sdc1 - press ENTER key to reboot...sd 7:0:0:0: [sdc] Synchronizing SCSI cache
sd 7:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=DRIVER_OK

10 minutes ago, fateful-observatory3964 said:

I recently updated my Unraid server to the latest version, but upon reboot, the system fails to start

Does it still start if you revert to the previous OS?

For me, not a single exposed service/domain is working after updating to 7.2.5: all domains are not reachable externally resulting in an error code 522. Downgrading to 7.2.4 again did not resolve the issue. I depend on my services being reachable, so this is a serious issue for me.

Setup:

• Unraid 7.2.5 on Unraid Server A (Terramaster F4-242)

• Docker custom network type: macvlan on br0

• Nginx Proxy Manager (jc21/nginx-proxy-manager) on br0 with static IP 192.168.178.5

• ISP: Vodafone Germany, DS-Lite (IPv6-only external connectivity)

• Fritzbox 7530 AX with IPv6 port forwarding to NPM's GUA address

• Everything worked perfectly on 7.2.4 and all previous versions for years

What happened: After upgrading to 7.2.5 and rebooting, all externally exposed services became unreachable immediately. No other changes were made.

Root symptom: Cloudflare (acting as reverse proxy) returns 522 (Connection Timed Out) for all domains.

Diagnosis via tcpdump on br0:

Cloudflare → NPM: Flags [S]  (SYN arrives correctly)
NPM → Cloudflare: Flags [S.] (SYN-ACK sent, hlim 255)
Cloudflare → NPM: Flags [S]  (SYN repeated — ACK never arrives)

The SYN-ACK leaves the Nginx Proxy Manager (on unraid server A) (hlim 255 confirms: it exits the host) but never reaches Cloudflare. The TCP handshake never completes. Notable: cksum incorrect on all outgoing SYN-ACK packets from the macvlan container.

What was tried:

• Fixed MAC address for NPM container (new Docker 29 requirement) ✓

• Confirmed Fritzbox port forwarding points to correct IPv6 GUA (2a00:...) ✓

• Fritzbox rebooted multiple times ✓

• NPM container recreated, database restored ✓

• Downgrade to 7.2.4 — problem persists (MAC remains fixed, IPv6 unchanged)

• ethtool tx/rx checksumming disabled on br0 and eth0 — no change

• iptables/ip6tables checked — no blocks on port 443

Key observation: The cksum incorrect on SYN-ACK packets from the macvlan container suggests a checksum offloading issue introduced with Docker 29 / kernel 6.12.85-Unraid on macvlan over br0. This may cause intermediate routers or Vodafone's DS-Lite AFTR gateway to silently drop the packets.

System:

• Unraid 7.2.5 (downgraded to 7.2.4 again, problem remains)

• Docker 29.3.1

• Kernel 6.12.85-Unraid

• Network: macvlan on br0

• ISP: Vodafone DE, DS-Lite, AFTR: 2a00:0:cff:34a0::1

Edited May 3May 3 by Gekko

15 hours ago, fateful-observatory3964 said:

The boot process halts with errors indicating that the xHCI host controller is dead,

Does it work if you boot with 7.2.5 with a stock install, without restoring any of your config?

13 hours ago, Gekko said:

For me, not a single exposed service/domain is working after updating to 7.2.5

Please create a new thread in the general support forum and post the diagnostics.

Whenever i update Unraid, it messes up the Nvidia drivers for me. Because i have one GPU that needs v580.159.03 and it updates my driver to the latest even though i had v580.159.03 selected. Not sure this is connected to Nvidia plugin or Unraid.

28 minutes ago, snoopy86 said:

Whenever i update Unraid, it messes up the Nvidia drivers for me. Because i have one GPU that needs v580.159.03 and it updates my driver to the latest even though i had v580.159.03 selected. Not sure this is connected to Nvidia plugin or Unraid.

Plugin dev has fixed that so it should no longer be an issue in the future

5 minutes ago, Kilrah said:

Plugin dev has fixed that so it should no longer be an issue in the future

I updated the plugin to version 2026.05.01 before the Unraid update, and the outcome was the same.

Edited May 4May 4 by snoopy86

Just now, snoopy86 said:

I updated the plugin to version 2026.05.01 before the Unraid update, and the outcome was the same.

Should report that in the plugin thread then since it's not related to the OS itself and would have more chance of being seen

On 5/2/2026 at 10:15 AM, BTrudgill said:

Since upgrading to 7.2.5 my nextcloud instance isn't accessable, via local ip or via cloudflare, can't figure out why. Also my server has gone from ~10% idle to 70% idle usage with php-fpm: pool www being the culprit.

Any ideas? Will have to downgrade if I can't figure it out today.

Having the same issue but then for all my docker containers.

I already opened an support ticket (#27695) Hoping they will respond fast!.

I already tried downgrading wich works.

I finally let go of version 7.1.4, which has been incredibly stable, and upgraded to 7.2.5. The only issue I ran into was:

After upgrading to Unraid 7.2.5 (Docker Engine 27 → 29), all containers on the br0.5 ipvlan custom network failed to start with Error response from daemon: invalid pool request: Pool overlaps with other one on this address space. The root cause was a pre-existing manual route override in /boot/config/go that was needed for the old ipvlan host-access workaround but became actively harmful under Docker 29's stricter network management. The route caused Unraid's rc.docker to silently graft 172.16.5.0/24 onto br0 (mgmt) instead of creating it as a proper child network on br0.5.

Fix: Comment out the legacy route in /boot/config/go, fix docker.cfg custom network entries, delete local-kv.db cache, reboot.

I wanted to share this in case someone else runs into the same issue.

Edited May 8May 8 by gurulee

On 4/30/2026 at 2:36 PM, SpencerJ said:

Docker containers may receive a new dynamically generated MAC address each time they are created -

Is there a way to ensure all my current Docker containers are assigned their current MAC addresses before performing the update?

55 minutes ago, Daniel15 said:

Is there a way to ensure all my current Docker containers are assigned their current MAC addresses before performing the update?

you'll need to update your container templates manually, but here's a cli one-liner to give you a table of info you need (container name, ip and mac address):

docker ps -q | xargs docker inspect \
  --format '{{.Name}} {{range .NetworkSettings.Networks}}{{.IPAddress}} {{.MacAddress}}{{end}}' \
  | column -t

4 hours ago, Daniel15 said:

Is there a way to ensure all my current Docker containers are assigned their current MAC addresses before performing the update?

22 hours ago, NoRaid99 said:

To keep the same old mac adresses of the docker conainers I did stop all dockers before the update, unticked the "auto start", updated and rebooted. Then it is important to change the templates from the docker containers before they start the first time and set the old fixed MAC.

This way all did stay the same like before.

Retried the update. This time 7.2.3 --> 7.2.6 on the Unraid system clocking the Update Available flag in the banner.

This worked correctly, no issues. No problem with Boot Failure. 7.2.4-->7.2.5 must have been a fluke.

-- Tom