For a reason unknown, going from 7.1.2 to 7.1.3, back and forth, removed the "Custom : br0" network I had in docker, to attribute to containers a custom IP.

Worse, when you go into Settings > Docker, you can see for example that br0 seems to be enabled...

Long story short, that's because the br0 is "available", but is not "enabled".

This might be because of static IP adresses and netmasks, that didn't pose a problem before and suddently, any netmask other than /24 for IPV4 and /64 for IPV6 is a problem....

I solved it by doing the following.

• Remove all custom networks from your dockers, set them to "none"

• Make sure to stop VMs, stop Docker.

• Have your Network Settings setup to "Enable Bridging = Yes"

• Bridging members of br0:eth0 if that is your interface

• Prefer a static ip address for IPV4 and ipV6

• !! Make sure your static IPV6 address has a /64 netmask and your IPV4 a /24 netmask

• Go back to Settings > Docker > choose IPVLAN

• Enable IPV4 custom network and IPV6 if needed

• Start/enable the docker service

• Make a first assesment in your docker templates to see if the custom networks went back online automatically just by correcting netmasks. Please report this if it did for you.

• If the network didn't create itself : Enter the terminal

  docker network prune

  docker network create -d ipvlan --subnet=192.168.x.0/24 --gateway=192.168.x.x --ipv6 --subnet=xxxx:xxx:xxx:xxxx::/64 --gateway=xxxx:xxx:xxx:xxxx::1 -o parent=br0 custom

This last docker command is valid for IPV6 and IPV4 as well

Go back into your docker templates and select the new "Custom" network

Remember in the docker template to enter the "IPV4,IPV6" addresses separated by a comma

Example for my adguard (IPV6 hidden for privacy purposes, but I use the same last numbers as the IPV4 address to help)

192.168.8.252,xxxx:xxx:xxx:xxxx::252

You should be good to go.

REMEMBER this is now a "custom network" that will NOT be preserved if you don't change that

Edited June 26, 20251 yr by LGFS

Thanks for the info. If I understood well you were hit by a known bug of 7.1.3... But 7.1.4 should have fixed that. Hence my question: why do you list 7.1.4 in the subject of this topic? Is this problem also happening with 7.1.4?

Thanks again.

Yes, this problem is also happening when going from 7.1.2 to 7.1.4, in my case.
I'm also listing all those 3 versions for people that will also eventually end up destroying their custom networks by deleting network.cfg or docker.cfg in their USB/Flash folder like I did see sometimes.

I did :

• 7.1.2 > 7.1.3 : lost br0

• revert back to 7.1.2 : restored br0

• 7.1.2 > 7.1.4_rc1 : lost br0

• revert back to 7.1.2 : restored br0

• 7.1.2 > 7.1.4 stable release : lost br0 (lost my patience there)

• revert back to 7.1.2 : restored br0

• 7.1.2 > 7.1.4 stable release : lost br0 again and my mind with it, decided to fix it myself

There should be a simple check to backup custom docker networks OR to allow creating them in the GUI.....

Right now, I don't know of any other way than to do it via terminal

Edited June 25, 20251 yr by LGFS

For most users this issue is resolved in 7.1.3 and 7.1.4

If you still encounter issues in 7.1.4, please open a bug report and provide diagnostics for further investigations.

I did provide 7.1.3 diagnostics a while ago and removed them (here https://forums.unraid.net/bug-reports/prereleases/unraid-os-version-714-rc1-available-r3912/?&tab=comments#comment-34470)

My belief is that I might have been using a custom br0 with an IPV6 prefix that was NOT /64 everywhere in the system (like it ended up being /128 in the diagnostics but not in the GUI of the docker manager).
Somehow, by removing and creating a new br0 with the correct prefix, it is working again.

Since I fixed the problem, I don't think "fixed" diagnostics will help any more ?

I'll try to provide my old 7.1.2 "working" diagnostics, 7.1.3 "failed" diagnostics and again, "fixed" 7.1.4 diagnostics to help the team, asap

If you still have an issue in 7.1.4 and know how to reproduce, that will help a lot.

Docker doesn't allow /128 subnets, because this is a single host address and prevent other hosts (containers) from joining this subnet.

Here are:

• The 7.1.3 diagnostics, with the problem (lost the initial 7.1.2)

• The 7.1.4 with my manual fix

I saw that in the diagnostics there was the "previous syslog" so you might be able to piece the puzzle together ?

Since I fixed it, the only culprit to me was "just updating FROM 7.1.2" (whatever the final version : 7.1.3, 7.1.4_RC1, 7.1.4)

Maybe there was a bug in 7.1.2 that allowed something that was removed....

NOTE: I was scared my effing IPV6 was leaked in the syslogs although I clicked "anonymyze", so you might see 2a01:e0a:xxx:xxxx with way more XXXX, I did a find-replace, need to educate myself on IPV6

unraid-diagnostics-20250625-2006_7.1.4 manually fixed.zip unraid-diagnostics-20250609_2247_7.1.3_br0 gone.zip

Edited June 25, 20251 yr by LGFS

Your static IPv6 configuration is wrong for eth0.

• Stop the array

• Go to Settings -> Network Settings -> Eth0

• Change the prefix to 64 (see example below)

• Start the array

Docker should now be able to properly create the custom network.

I just modified the IPV6 prefix.
Since I'm using a custom br0 using "docker network create" this might not matter until the next update, will post & update OP to add this.