After having to restore piecemeal yesterday because Unraid NGINX wasn't loading, I'm now having an issue with docker host access to custom networks not working.

 

Docker is set to ipvlan, I don't have any wifi device in the server, and I've tried disabling, starting docker, then and reenabling the "Host access to custom networks" setting to no avail.

 

Prior to upgrading, I had NGINX Proxy Manager working with Plex and a couple of other dockers on a custom network, and stuff like Tautulli on the default bridge.

 

Now, NGINX can't reach anything on the bridge (it's on a custom network) and returns 502 errors, and Tautulli can't access Plex on it's custom network. NGINX is fine with stuff that isn't on the bridge - i.e. Plex.

 

Attached diagnostics:

babel-diagnostics-20250507-1326.zip

Edited May 7, 20251 yr by husqnz

Bump

 

Anyone else seeing this unexpected behaviour?

 

I don't really want to roll back as I've just pulled the trigger on an Arc B580...

Decided to check the bug reports forum as a hail mary and found this post from @Naticus which seems to solve the problem!

 

3 hours ago, Naticus said:

I just ran into a similar issue where the host couldn't ping anything on br0 despite allowing host to reach custom networks.  I don't have an IPv6 setting in my Docker settings (maybe because IPv6 is completely disabled), but what fixed it was:

1. Stop Docker
2. Change "Docker custom network type:" to macvlan
3. Start Docker, verify ping works on br0 containers
4. Stop Docker
5. Change "Docker custom network type:" to ipvlan
6. Start Docker, again verify ping works on br0 containers

May  7 13:26:10 babel sshd-session[1337454]: Close session: user root from 192.168.1.27 port 40096 id 1
May  7 13:26:10 babel sshd-session[1337454]: Received disconnect from 192.168.1.27 port 40096:11: Disconnected by application

What is this all about.  Happening constantly multiple times per second ad nauseam

1 minute ago, Squid said:

May  7 13:26:10 babel sshd-session[1337454]: Close session: user root from 192.168.1.27 port 40096 id 1
May  7 13:26:10 babel sshd-session[1337454]: Received disconnect from 192.168.1.27 port 40096:11: Disconnected by application

What is this all about.  Happening constantly multiple times per second ad nauseam

Home assistant integration, it's very noisy. I actually don't need it anymore as I'm using the NUT plugin instead to get UPS status, so will kill it!

 

Edited May 7, 20251 yr by husqnz

On 5/8/2025 at 12:47 AM, husqnz said:

1. Stop Docker
2. Change "Docker custom network type:" to macvlan
3. Start Docker, verify ping works on br0 containers
4. Stop Docker
5. Change "Docker custom network type:" to ipvlan
6. Start Docker, again verify ping works on br0 containers

 

 

Fixed it for me thanks a lot!

Edited May 9, 20251 yr by Patrick._.sw

The workaround solved the issue for me as well, thanks for that, but unfortunately, I have to reapply it every time the server reboots. 😞

Before Unraid 7.1, I had no issues running Docker containers on a custom network behind Nginx — everything just worked after startup.
Since updating, the setup requires multiple manual steps after each reboot to restore full functionality. This is quite inconvenient and feels like a regression compared to earlier versions.

 

I'm also experiencing severe performance issues with my VMs since upgrading to Unraid 7.1.x — they're now running at a snail's pace, despite being installed on fast NVMe drives.

 

My Windows 11 VM barely manages to boot and then freezes shortly after. I haven't been able to identify the cause yet, and troubleshooting is difficult because a) the boot time is painfully long, and b) if I'm even slightly distracted, the VM crashes and has to be forcefully shut down and restarted.

 

And my Linux Mint VM used to run very fast before the update to Unraid 7.1, but now it feels like it's operating with the handbrake on — even though, just like my Windows 11 VM, it has access to 6 out of 8 CPU cores (12 threads) and 32 GB of RAM.

 

My Unraid server has a total of 128 GB of DDR4 RAM, and the VMs usually don't run simultaneously — I only start them when I need them.

3 hours ago, Thomas1978 said:

The workaround solved the issue for me as well, thanks for that, but unfortunately, I have to reapply it every time the server reboots. 😞

Before Unraid 7.1, I had no issues running Docker containers on a custom network behind Nginx — everything just worked after startup.
Since updating, the setup requires multiple manual steps after each reboot to restore full functionality. This is quite inconvenient and feels like a regression compared to earlier versions.

 

I'm also experiencing severe performance issues with my VMs since upgrading to Unraid 7.1.x — they're now running at a snail's pace, despite being installed on fast NVMe drives.

 

My Windows 11 VM barely manages to boot and then freezes shortly after. I haven't been able to identify the cause yet, and troubleshooting is difficult because a) the boot time is painfully long, and b) if I'm even slightly distracted, the VM crashes and has to be forcefully shut down and restarted.

 

And my Linux Mint VM used to run very fast before the update to Unraid 7.1, but now it feels like it's operating with the handbrake on — even though, just like my Windows 11 VM, it has access to 6 out of 8 CPU cores (12 threads) and 32 GB of RAM.

 

My Unraid server has a total of 128 GB of DDR4 RAM, and the VMs usually don't run simultaneously — I only start them when I need them.

Yeah - having to reapply after reboots is very annoying. I've left mine in macvlan for now as that doesn't seem to be impacted and I can get by with it. I'll switch it back to ipvlan when the issue is fixed - there's a bug report which will hopefully bring that fix.

 

For the VMs - I'd suggest making a new post with diagnostics attached so that some of the super helpful experts can jump on it and have a look

as it apears you ahve someting working again...

 

AS This still works, and I have yet to have a issue with this option...

More do to unifi as I also edit the bridges IP to set to a static for macvlan...
as I static set my unraid to ip 192.168.2.251
 

#!/bin/bash

# Wait at boot
sleep 30

echo "Fixing Docker shim bridge..."
ifconfig shim-br0 down 2>/dev/null
ip link set shim-br down 2>/dev/null
ip addr flush dev shim-br0
ip addr add 192.168.2.250/24 dev shim-br0
ip link set shim-br0 up
echo "Docker shim interface configured."

ip a

this way the bridge is not reusing 192.168.2.251 and i set it to 192.168.2.250

I haven't ever lost host access and its abilty to communicate to the lan without this script... I can only assume some network misconfiguration.

review:

 

Going over the different docekr network types...

Edited May 12, 20251 yr by bmartino1

also ther have been complaints with home assist due to unraid brdige 

use dokcer inspect comands to confirm...

as home asisntt wants to use ipv6 while unraid forced the docker bridge to use ipv4

 

#!/bin/bash

# Delay before starting
sleep 10

# Apply sysctl settings
apply_sysctl_settings() {
    echo "Applying sysctl settings..."
    sysctl -w net.ipv6.conf.all.forwarding=1
    sysctl -w net.ipv6.conf.br0.accept_ra=2
    sysctl -w net.ipv6.conf.br0.accept_ra_rt_info_max_plen=64
    sysctl -w vm.overcommit_memory=1

    echo "Verifying sysctl settings..."
    sysctl net.ipv6.conf.all.forwarding
    sysctl net.ipv6.conf.br0.accept_ra
    sysctl net.ipv6.conf.br0.accept_ra_rt_info_max_plen
    sysctl vm.overcommit_memory
}

apply_sysctl_settings

 

you can set ipv6 forward to restore home assist ipv6 over a tapipv4 bridge.

 

i run both script at first array start to fix docker networking 

as noted here with unraid v6.9 issue moving forward due to ipv6 and ipv4 breaking docker network as when ipv6 is enabled its is usually defaulted too and doesn't always communicate across the bridge...

 

 

Edited May 12, 20251 yr by bmartino1

You know what's weird? I've experienced this behaviour long before the 7.1 update but only if my server shut down unexpectedly. SInce I've aquired UPS there were very few dirty shutdowns, only like 2 or 3 a year, so I didn't bother looking for a fix and just remembered I have to do one extra reboot and I'm fine. But now I wonder if there's a relation with this now prevalent misbehaviour. 

 

Oh yes, and massive thank you to @husqnz and @Naticus, you saved my nerves. I almost bought a Chromebox and turned it into a standalone nginx/pi-hole machine, which would be awesome and I would really enjoy doing it, but have no time for 😅.

I just ran into this issue and have found two others that I suspect are the same issue.

 

https://forums.unraid.net/topic/190305-712-docker-vlan-host-comms-broken/