I just encountered a problem, where my NAS VM isn't reachable anymore and all my depending docker services, which depend on the NAS, went down.

I use the main bridge br0 to attach all my VMs to the main subnet and never had bigger problems except my personal macvlan-bug debacle a year ago.

Since then the virtual networks ran flawelessly, until I had to restart my machine last week.

Since then, if the docker service is enabled, my NAS can not be pinged and also no shares can be mounted. If I disable the docker service the problem remains.

I have to restart the machine first without the docker service enabled to be able to mount shares again (and ping the NAS and vice versa / all pings and mounts from Unraid with the Truenas vm as a target)

Below you see a ping that is interuppted by the startup of the docker daemon.

root@Icarus:~# ping 192.168.0.116

PING 192.168.0.116 (192.168.0.116) 56(84) bytes of data.

64 bytes from 192.168.0.116: icmp_seq=1 ttl=64 time=0.450 ms

64 bytes from 192.168.0.116: icmp_seq=2 ttl=64 time=0.315 ms

64 bytes from 192.168.0.116: icmp_seq=3 ttl=64 time=0.389 ms

64 bytes from 192.168.0.116: icmp_seq=4 ttl=64 time=0.402 ms

64 bytes from 192.168.0.116: icmp_seq=5 ttl=64 time=0.556 ms

64 bytes from 192.168.0.116: icmp_seq=6 ttl=64 time=0.492 ms

64 bytes from 192.168.0.116: icmp_seq=7 ttl=64 time=0.384 ms

64 bytes from 192.168.0.116: icmp_seq=8 ttl=64 time=0.280 ms

64 bytes from 192.168.0.116: icmp_seq=9 ttl=64 time=0.572 ms

64 bytes from 192.168.0.116: icmp_seq=10 ttl=64 time=0.505 ms

64 bytes from 192.168.0.116: icmp_seq=11 ttl=64 time=0.482 ms

64 bytes from 192.168.0.116: icmp_seq=12 ttl=64 time=0.281 ms

64 bytes from 192.168.0.116: icmp_seq=13 ttl=64 time=0.439 ms

64 bytes from 192.168.0.116: icmp_seq=14 ttl=64 time=0.278 ms

64 bytes from 192.168.0.116: icmp_seq=15 ttl=64 time=0.318 ms

From 192.168.0.254 icmp_seq=16 Destination Host Unreachable

From 192.168.0.254 icmp_seq=17 Destination Host Unreachable

From 192.168.0.254 icmp_seq=18 Destination Host Unreachable

From 192.168.0.254 icmp_seq=19 Destination Host Unreachable

From 192.168.0.254 icmp_seq=20 Destination Host Unreachable

From 192.168.0.254 icmp_seq=21 Destination Host Unreachable

I will add a syslog later, where I turn on the service.

I actually thought I fianally understood the whole macvlan network thing, but apparently not. So here is my configuration:

Unraid version:

• error started in 7.1.2

• persisted in 7.1.4
  

Network:

• Bonding: OFF

• Bridging: ON -> creates br0

• Bridging Members Of Br0: eth0

• IPv4 Address Assignment: Static (I had it on DHCP but to be on the safe side I changed it)

Docker:

• Docker Custom Network Type: macvlan -> with the intention to assigning ip addresses for selected containers

• Host Access To Custom Networks: Enabled

• Preserve User Defined Networks: Yes (created by me manually and by Portainer)

VM:

• Default Network Source: br0

The network snippet from the XML of the NAS VM:

<interface type='bridge'>

<mac address='52:54:00:a4:70:54'/>

<source bridge='br0'/>

<target dev='vnet0'/>

<model type='virtio-net'/>

<alias name='net0'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>

</interface>

I tried a lot of suggestions for troubleshooting general macvlan prboblems like switching to non-bridged macvtaps or creating a custom newtork,

but none of the suggestions I found in the forum and the docu helped me to solves this, while keeping the IP and haveing a connection between host and vm.

Unfortuantely I can not explain what change from my side caused this, but it worked for over a year, without me changing anything in the network settings or the XML of the NAS (I never touched them after I got it to work).

Thanks for any help :)

Edited August 3, 2025Aug 3 by blacklight

also I just saw the 192.168.0.254 address that I overlooked the whole time, and I have no idea what causes the address. My Unraid address is 192.168.0.10 and the one of the NAS is 192.168.0.116.

Custom networks in the Docker page are enabled (ticked br0, br3 and br0.10 with DHCP on all three of them)

It turns out that it was a remnant docker network I created via Portainer.

I found this entry:
192.168.0.0/24 dev br-75ff69ec12b1 proto kernel scope link src 192.168.0.254 linkdown

with docker network ls

Which has the same exact subnet as the one on the bridge. From my understanding I thought the same subnets are possible in isolted docker networks (like the shim-networks),
so I can not explain why this error occured.

Deleting the network and restarting the service fixed the communcation error.