May 14, 20251 yr I have updated to 7.1.2, and I am not able to communicate with my containers anymore between my host and docker network. I can read logs and exec into containers fine. Docker settings: I use macvlan Host access to custom networks is Enabled Preserve user defined networks is still Yes I see this note: https://docs.unraid.net/unraid-os/release-notes/7.0.0/#issues-using-docker-custom-networks I attempted to set `DHCP pool: 192.168.0.0/25 (128 hosts)`, but I am still not able to access anything on my docker network from my host network. Containers of network type host are working fine. I have attached my diagnostics. My docker network still looks as I expect/is bridged to my host. docker network inspect docker [ { "Name": "docker", "Id": "", "Created": "2023-07-04T10:08:33.990677046-05:00", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "172.18.0.0/16", "Gateway": "172.18.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": {...}, "Options": {}, "Labels": {} } ] What does "Not able to connect" mean? Trying to access a particular container via the host network: curl -v 192.168.0.244:8989/health * Trying 192.168.0.244:8989... * connect to 192.168.0.244 port 8989 from 192.168.0.244 port 40552 failed: No route to host * Failed to connect to 192.168.0.244 port 8989 after 1497 ms: Could not connect to server * closing connection #0 Trying to access that container from another container in the same docker network: curl -v 172.18.0.28:8989/health * Trying 172.18.0.28:8989... * Connected to 172.18.0.28 (172.18.0.28) port 8989 > GET /health HTTP/1.1 > Host: 172.18.0.28:8989 > User-Agent: curl/8.5.0 > Accept: */* > < HTTP/1.1 302 Found < Content-Length: 0 < Date: Wed, 14 May 2025 23:15:41 GMT < Server: Kestrel < Location: http://172.18.0.28:8989/login?returnUrl=%2Fhealth < * Connection #0 to host 172.18.0.28 left intact Please let me know if you have any ideas. ms-diagnostics-20250514-1756.zip Edited May 14, 20251 yr by paperblankets More details
May 15, 20251 yr Community Expert See if this helps https://forums.unraid.net/bug-reports/stable-releases/docker-container-dont-start-br0-not-found-after-update-r3791/#findComment-33799
May 15, 20251 yr Author 5 hours ago, JorgeB said: See if this helps https://forums.unraid.net/bug-reports/stable-releases/docker-container-dont-start-br0-not-found-after-update-r3791/#findComment-33799 I'm unable to set the type to ipvlan temporally. I'll try to dig into why that is the case this evening.
May 15, 20251 yr Author 23 hours ago, JorgeB said: Enable bridging for eth0, then try again. Enabling bridging did work (I thought that was on the whole time), I could set ipvlan. Starting docker with ipvlan set was still not accessible from my host network, setting it back to macvlan also didn't fix my access. Since I thought bridging was enabled before now, I now wonder if other network settings might be different than what I originally set them to. I also wonder if something with tailscale could be causing this (these are not tailscale enabled containers, but I know some changes happened between host and tailscale networking recently) Edited May 16, 20251 yr by paperblankets
May 16, 20251 yr Author Solution The solution was to Delete and recreate my custom docker network. Stop all containers docker stop $(docker ps -a -q) Remove the custom network docker network rm <YOUR_NETWORK_NAME> Recreate the network docker network create -d macvlan --subnet=<YOUR_SUBNET> --gateway=<YOUR_GATEWAY> -o parent=br0 <YOUR_NETWORK_NAME> Restart unraid For me unraid was quite unhappy. It failed to mount an unassigned device, which caused the docker engine to fail to start. Restart a 2nd time. Restart each container After this my network existed as expected (same as before), but the docker network was now accessible from br0. Unraid managed containers: I had to edit each container, change it's network to none, and then back to my custom docker network (Only one save). Compose managed containers: I had to down each stack, and then I could up it again. Some stacks with complex network configurations had additional fiddling. After the above steps, I can reach containers on my custom docker network from their br0 forwarded ports/as expected. Other notes! I see this in my logs: kernel: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. May 16 11:03:11 ms I wonder if it's related to the behavior change, or if after some part of unraid updating I just had to recreate my docker networks. Edited May 16, 20251 yr by paperblankets Details
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.