• Lost Access to Host from Docker on Custom br0 after reboot

    • Solved Minor

    I have a few dockers running on br0 with their own IPs. after a reboot I lose access to the Host from these dockers.


    If I open the console for the docker and curl to the host it fails. I then have to stop the docker service, disable the allow host access to custom networks hit apply, enable the allow host access to custom networks again, hit apply and finally start the docker service and hit apply. then everything works beautifully. If I run curl on the host now it instantly responds.



    Below has info on this, and to me it is not solved...



    User Feedback

    Recommended Comments

    I am on 6.9.2 and I just had this issue.  After reboot it was not working so I had to stop Docker, disable that option, apply, enable, apply and reenable docker to get it working again.

    Link to comment

    My Unraid server is running on 6.9.2 as well and after I had to reboot my server I also had to do the same steps as @B_Sinn3d described. After the reboot pinging containers in br0 was not possible anymore even the option was enabled.

    Link to comment

    I'm also still randomly encountering this problem. This issue doesn't seem to be finally solved...

    I have "Allow access to host networks" checked/active.

    My Home Assistant Docker (host network) sometimes looses connection to some other docker containers on different vlans (e.g. ispyagentdvr on custom br0.6 network, motioneye on custom br0.5 network, frigate on custom br1.15 network).

    Stopping and starting the docker service always solves this issue. A reboot of unraid sometimes solves this issue, sometimes it's raising this issue. I have two NICs and four VLANs.

    Link to comment

    Ok, I have better informations now. I know what happens but still don't know the cause...


    I am on 6.9.2 and also randomly encounter the problem to loose connection from host to some docker containers mostly after an reboot of unraid.
    Sometimes this issue aslo comes out of the blue. 
    I don't know exactly when it appears on my running Unraid Server (out of the blue) because I may realise this some days after it appeared... But I can imagine that it may somtimes happen after a automatic backup of appdate with the plugin "CA appdata backup/restore V2" because this plugin stops and resatrs the running docker container. 


    Last time it happend: Yesterday.
      Probably at 1:00 AM. My server just rebooted out of the blue because of another problem (I'm investigating...)
      After this: no shim networks. Resolved today at ~08 AM
      (see attached log)


    My relevant configuration:

    I have

    • Network: two NICs and four VLANs.
    • Docker: "Allow access to host networks" checked/active.
    • Dockers and VMs in those VLANs (br.01, br0.5, br0.6, br1.5, br1.16)
    • A Home Assistant Docker (host network) that looses connection to some other docker containers on different vlans (e.g. ispyagentdvr on custom br0.6 network, motioneye on custom br0.5 network, frigate on custom br1.15 network).


    This raises this issue:

    • Reboot of unraid: sometimes
    • Running unraid: sometimes (because of plugin "CA appdata backup/restore V2"??)


    This workaround solves this issue temporary:

    • Always: Stopp docker service, de-/reactivate "Allow access to host networks", restart docker service
    • Sometimes: Reboot of unraid


    I didn't try manually readding the shim networks but in this post "shim-br0-networs-in-unraid" it seems to be a possible workaround:



    So the problem are the shim networks!?

    • They sometimes aren't set at boot. (Why?)
    • They sometimes get lost. (Why?)


    What are shim networks?:
    shim networks should be created when the Docker setting "Host access to custom networks" is enabled.
    This allows Unraid to talk directly with docker containers, which are using macvlan (custom) networks.
    But those shim networks are not allway created after reboot!


    So it's still a NOT solved bug:


    What worries me, is that this is a bug that seems to persist in Unraid 6.10-rc3:


    Perhaps a user-script could detect missing shim networks and readding them? Any ideas or hints??


    Please see the pictures and the log I attached.


    Before stopping docker service.



    After de-/reactivating "Allow access to host networks" followed by restarting docker service



    See the (commented) log file:


    Link to comment

    There might be a race condition at system start up, when you use DHCP to obtain an IP address and the DHCP is slow to respond. If no IP address is yet assigned, the creation of the shim network fails.


    I use a static IP assignment and shim network is properly created at start up (no race condition).


    Unraid 6.10.0 has an extra check to wait for the interface to become physically up before assigning the shim network, but this does not protect against slow DHCP assignments.


    Link to comment

    hmm, my Unraid Server has static IPs, all also of my dockers and vms


    Oh wow, I didn't now that unRAID 6.10 was released!! Fantastic!

    I just upgraded (flawlessly).

    Booted two times since then without any problems. I will test again later and report here.


    Link to comment

    Ok, it seems to be fixed for me.

    I rebooted several times, updated unriad to 6.10.1 ans everything (shim network) works as expected.



    I realized that unraid does not create the shim network after recovering (rebooting) from an unraid crash.

    I still don't know exactly why it crashes...but my raspi (with pivccu homematic CCU3) crashes at the same time. I have the presumption, that it's my raspi crashing first and unraid crashes because of the raspi. They are on the same socket strip... Investigating.........


    So this bug report can be closed again!



    Link to comment

    Hello , is still have this problem on 6.10.3 after restart host accest doesn't work, i have to stop the docker service disable host access  then enable host acess and start the docker service.

    I am using a opnsense VM as my router so there is no network when unraid is startig but all the interfaces have a static address.

    This affects dockers that are not running on the main interface but are tryining to access a docker on the main interface(my Apache dockers are on vlan 20 , but my mysql docker is running on the host interface) .

    Link to comment

    It works fine when using a static IP address assignment for Unraid.


    Using DHCP may cause a race condition, and the shim network is not created when your DHCP server is slow in responding.

    Link to comment

    When I reboot my Unraid server the the shim networks are created and everything is fine.

    But it does not create the shim networks after an automatic reboot after a crash or power outage.

    I don't know what should be the difference between a wanted manually reboot and an automatic reboot after crash or power outage??


    Link to comment
    On 7/7/2022 at 5:14 AM, bonienl said:

    It works fine when using a static IP address assignment for Unraid.


    Using DHCP may cause a race condition, and the shim network is not created when your DHCP server is slow in responding.

    Happens with static ip as well

    Link to comment

    Just ran across this as well.  Glad it's not just me...I thought I'd found a fix months ago, and now couldn't remember what it was.  I'm guessing I'd inadvertently fixed it with the steps above back then.
    Above steps do fix for me as well....bookmarking/following this thread.

    Link to comment

    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.

    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

  • Status Definitions


    Open = Under consideration.


    Solved = The issue has been resolved.


    Solved version = The issue has been resolved in the indicated release version.


    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.


    Retest = Please retest in latest release.

    Priority Definitions


    Minor = Something not working correctly.


    Urgent = Server crash, data loss, or other showstopper.


    Annoyance = Doesn't affect functionality but should be fixed.


    Other = Announcement or other non-issue.