• docker "host access to custom networks" needs to be reenabled on each unsafe shutdown

    alturismo

    By alturismo

      • Annoyance

    just to keep this issue alive as there are more open questions regarding this and its still open in 6.10 rc2

     

    description is simple as the topic, whenever there was a unsafe shutdown, starting unraid with docker setting

     

    image.thumb.png.7ba4b956ff76a06861609d5286448499.png

     

    will result in a non working state, stopping/starting docker service or rebooting clean resolving the issue.

     

    easy to reproduce and annoying when you externally working on the mashine and hard reboot externally while using as sample ssh guac to access it again, but doesnt work as described above, so only VPN backdoor to restart it.

     

    may a workaroud possible if its a bigger issue ? like you can trigger parity after a unclean shutdown, trigger a docker service restart too ?

     

    tested here from 6.92 until today 6.10 rc2 on 4 different mashines with the same result, open issues as reminder

     

     

    ...

     

     

    • Like 1
    Go to reports Prereleases

    User Feedback

    Recommended Comments

    Benni-chan

    i have the same problem.

    after an unclean shutdown (rc2 crashes sometimes, there are many other bug reports about this), i have to disable and reenable this setting. very annoying.

    • Like 1
    Link to comment
    bonienl

    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
    alturismo
    On 7/7/2022 at 12:13 PM, 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.

    sorry @bonienl but i cant confirm this, as i didnt had any "unsafe" shutdowns lately i just forced one and ...

     

     

    image.thumb.png.ec4da88cb8bae4489539d82fc0b4f5b6.png

     

    and i use a static assignement since day 1 i use unraid (all local devices here use static ip's here)

     

    image.thumb.png.1689c33f04d26bbe110c5e4523164d77.png

     

    docker setting

     

    image.thumb.png.17a98e13558f2caccabaf420bc15cf23.png

     

    so for now i have to stop/start docker service to get the "host access" back to work or make a clean restart ...

     

    then its back again

     

    image.thumb.png.14861a867906f70bf91e7708ad7a8b8c.png

     

    as i stated, no chance to make a simple routine ? unclean shutdown = docker service restart ;)

    image.png

    Link to comment
    arturovf
    9 hours ago, ionred said:

    Can confirm all unraid related ips on my system are static as well 

    x2, static ip as well

    Link to comment
    lucidnx

    I am just using bridge for all my containers, unraid uses DHCP client to get IP (2xNIC in LACP), and on every reboot, I need to turn docker off and on again. then it works. I am on 6.11.1, still present.

    Link to comment
    alturismo

    may as friendly reminder, 6.12 has still the same issue ...

     

    unsafe shutdown, reboot, most common ends in broken (missing shim) host access.

    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.

    Guest
    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.