• Serious issue with edited containers!

    • Minor

    I use technitium DNS server.

    This used to have a custom UNRAID container profile, but not any more.

    So now I install the generic container (as found in Apps with the name "dns-server").

    The default configuration does not work as is.

    I need to edit it with portainer to change a couple of paths and only then it starts.


    This is the change I do:

    /mnt/user/appdata/technitium-dnsserver/config	/etc/dns/config
    /mnt/user/appdata/technitium-dnsserver	/etc/dns

    Both as bind.


    Keeping the container out of "auto update", used to work fine.

    I updated only manually and could then RE-do the changes.

    Else, my whole LAN was left without DNS.


    BUT recently (and this is why I post here), the container seems to VANISH!

    I suspect maybe when checking (automatically) for updates. Even though I have set it to not auto-update.

    I mean, I have it running fine, then after a few hours I discover the container is not there any more!
    I have to go to "previous apps", re-add it (will not start like that), re-edit it (now it starts).


    This happened twice or three times the last few days!
    It is really serious, what can possibly remove the container from docker!?


    Previously, even if it tried to auto-update, at least it left me with a non-working but EXISTENT container.

    This disappearance thing, is new.

    Bonus question: Since the change to a working container is minor. How can I store this and re-use it instead of redoing it all the time? Maybe even be able to re-enable it to auto-update to the CORRECT one?

    User Feedback

    Recommended Comments

    I can reply to my own bonus question:

    If I edit the template and change default app data path to the correct one (i.e. /mnt/user/config to point to /mnt/user/appdata/technitium-dnsserver/config/), then I can add an extra path (I named it app data 2) and point /mnt/user to /mnt/user/appdata/technitium-dnsserver/. This solves the issue and the container can now auto-update!
    (if I don't add the first path, the container doesn't assume that /mnt/user/config is under /mnt/user as it was supposed, but instead does NOT make it a bind path at all and points to the wrong path).

    MY SOLUTION DOES NOT SOLVE THE BUG THOUGH! This is why I don't close this report.
    I mean, I corrected the issue, so I don't hit the bug, but the bug is still there and can probably hit others.
    The bug is that if container after update has an issue, something removes it from the container list!
    I suspect the coolpit is somewhere in the update script where the script removes the "old" container, before verifying that indeed the "new" one can be deployed. If the deployment fails, we are left with a removed container!


    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.