I have a few containers that are local access only, so I put them on the bridge rather than my custom VLAN.

 

I can't be 100% positive, but at some point, none of the containers on the bridge are accessible. They can ping the internet, but I can't bring up any UI pages using the IP:port assigned.

 

I went through my network settings following the config described in the 6.14 release notes (I use MACVLAN for my cutom networks), and on the Docker page, if I enabled the custom network for eth0 as described, I would lose access to the Unraid WebUI once Docker got started. I've restored the config I had so I can get back into the server, but all of the bridge mode containers are still down.

 

 

 

 

 

 

 

 

knoxx-diagnostics-20250402-1427.zip

Edited April 2, 20251 yr by aglyons

i think your fighting vlan cross traffic and access.

...

if at the unraid host and its booted in the gui mode, you may be able to access teh web page / port via the firefox web browers on unraid. i think you would be able to access the dockers web page..

becaeu you have a vlan on valn 2


in order to reach the docker if setup corectly, your computer would need to be on vlan 2.

further, 

this tells me your vlan 2 is the access to your subnet to docekrs. so a docekr set to 192.168.202.x can only be access on anotehr device that is also conected to vlan 2

review some data here first:

as you would need to make a docker network or use vlan 1 the default vlan to use the device that is not working. and tie the mac vlan docker to interface eth0

So if I had enabled the custom network on eth0 in the Docker settings, the Unraid UI becomes unavailable.

 

The thing is, I WAS able to access all containers on the bridge up until recently. I'm not sure what changed. I'm sure it wasn't anything I've changed, as I haven't changed anything regarding the network config for about a year now.

 

Currently, with eth0.2 enabled, the Unradi UI is available on the 200.x network and all my Dockers on eth0.2 (202.x) are accessible, as are all containers running in Host mode (200.x). It's only containers on the default bridge that are not accessible to incoming traffic. Outgoing traffic works fine AFAIK.

 

So, as stated, the Unraid UI is accessible with custom network eth0 disabled.

 

I just had a thought that when the system starts up and Docker has not started, it is still listening on eth0. If Docker is not set to start, the Unraid UI is fully accessible. When Docker kicks in, I suspect that eth0 interface gets replaced by br0 but the Unraid system remains set to respond to requests only on eth0, not br0. That switch does not get changed in the Unraid Networking listening interfaces config.

Edited April 3, 20251 yr by aglyons

If I go by the understanding that enabling the custom network to allow for the bridge to work, and instead of enabling the eth0 custom network, I assign a static IP to the eth0.2 VLAN custom network, that should be the bridge network accessible from x.x.202.x:[port]

 

But that doesn't happen. 

 

What has happened is that my Unraid UI is now accessible from both x.x.200.x and x.x.202.x, and still no containers on the default bridge are accessible.

(^^ I noticed and corrected that eth0.2 was added to the listening devices list. It is again only accessible from 200.x)

 

All this time, the containers on x.x.202.x and all containers on HOST (x.x.200.x) have been fully accessible.

 

I should add that this is only on the default bridge. I have some compose containers that create their own bridge networks, and both of those work fine.

 

 

 

Question to the devs (or those that know): Has the bridge kernel panic issue been resolved fully, or are we still relying on the workaround described in v6.14 release notes?

Edited April 3, 20251 yr by aglyons

So I gave up on troubleshooting the default bridge and created a new bridge network parented to eth0.

 

All containers moved to that new bridge are working as expected.