• 6.6.3 - Unable to remove Host Path from docker container


    IceNine451
    • Minor

    I found this issue recently while on 6.5 and it has persisted through to 6.6.3 so I thought I would report it. It is more annoying than a show stopper.

     

    I have a Docker container (Sonarr) that has several Host Paths configured. I have since emptied one of the shares that was mapped and removed the share itself, but I seem to be unable to remove the Host Path from the container. I can click the Remove button next to the Host Path in the container configuration page and the container will restart without using the share, then I'm able to delete the empty share itself. Before removing the mapping I cannot delete the empty share because UnRAID says it is in use.

     

    The path is not shown under the Volume Mappings under the Docker Container list at this point, but if I go to the container properties again the path is still listed. If I update the container the path will be used again and the empty share is recreated. So then I have to remove the mapping and delete the empty share again.

     

    I'm not sure what is causing the issue and I'm pretty sure I could fix it by rebuilding the container completely, but it seems like this should work the way I'm doing it by removing the volume mapping from the existing container.

     

    Let me know if more details are needed.

    tower-diagnostics-20181022-1415.zip




    User Feedback

    Recommended Comments

    More information is needed for us to try and recreate this issue.  I'm a little confused by your description.  First you say this:

     

    Quote

    I seem to be unable to remove the Host Path from the container.   I can click the Remove button next to the Host Path in the container configuration page and the container will restart without using the share

     

    So in the first sentence you say you can't remove the host path from the container.  In the second sentence, you say that you perform the exact operation required to remove the path and it works as expected.  So what's not working exactly? ;-)

     

    Then there's this:

     

    Quote

     if I go to the container properties again the path is still listed.

    What is "container properties"?  You mean the Edit Container page?

     

    Just an FYI, I did try to recreate the issue here of removing the host path mapping and then starting the container to make sure that it stays removed and it works for me.  Maybe I'm misunderstanding the problem?

    Link to comment

    You are on the right track, sorry if my initial description was unclear. I am following the correct operation to remove a host path from a container (open Edit Container page, click Remove button next to host path, click Apply button at bottom of Edit Container page) and while the host path will be removed from the container and no longer show under the Volume Mappings column on the Docker Containers page, the host path remains on the Edit Container page and will recreate the deleted share every time this container is updated.

     

    I actually updated the container today, so here is everything I am seeing on my end and what I have done / am doing:

     

    Done in the past:

    - Removed all files from a given share.

    - Deleted empty share from the Share Settings page for that share, via the Delete Share checkbox.

    - Removed Host Path mapping for that share for the Docker container from the Edit Container page.

     

    At this point the Host Path doesn't show in the Volume Mappings column in the Docker Containers page but continues to show under the Edit Container page for that container. The share is still deleted.

     

    Today:

    - Updated Docker container through the container update function on the Docker Containers page.

    - See share that was deleted listed in the container launch command, the share also shows again under the Volume Mappings column on the Docker Containers page and the share I deleted has recreated itself on the Shares page and I can see it again on the network.

    - Go to Edit Container page for this container and click Remove button next to Host Path I want removed and click Apply button at bottom of page.

    - The empty share is no longer listed on the launch command for the container.

    - The Host Path no longer shows under the Volume Mappings column on the Docker Containers page.

    - The Host Path continues to show on the Edit Container page, even though it doesn't appear to currently be being used by the container.

    - Delete the empty share again.

     

    I can stop/start or restart the container and the share won't be recreated, but if I force update the container then the phantom host path is used again and the share will recreate itself. My current problem seems to be that it is impossible to remove the host path from the Edit Container page and that setting is used whenever the container is updated, causing an empty share to be created every time.

    Link to comment

    Can you post the relevant xml file from /config/plugins/dockerMan/templates-user on the flash drive and also your diagnostics after doing replicating this again.

     

    But one comment

    12 minutes ago, IceNine451 said:

    - Updated Docker container through the container update function on the Docker Containers page.

     

    Part of the update process is to also update the templates with some certain information.  Notably in this case is the Config entries.  This means that if the template author has a config entry which you do not, then it gets added (for requirements of the app etc).  Net result is that it gets (*should*) added back in in this particular case. Doesn't completely explain your problem though as I can't replicate it myself, hence why I'm asking for the particular xml.

    Edited by Squid
    Link to comment

    Attached. I do see the share I'm trying to remove (/mnt/user/Alex TV) so I'm assuming it's not being removed from this xml file when I click the remove button on the Edit Container page, so is being recreated when I upgrade the container. I'm thinking the upgrade process isn't pulling that info from outside since I added the host path myself. Should I be able to edit this xml file directly to remove the host path and keep the empty share from getting recreated every time?

     

    Also, I just tried something else that yielded interesting results. I tried adding another Host Path to that container. What happened was the container started again with the path I've been trying to remove as well as the new path I added and all the paths that should be there. All the paths show normally on the Volume Mappings column in the Docker Containers page. But when I go to the Edit Container page for that container the new path isn't shown at all. And the new path also wasn't added to the XML file. When I removed the path I've been trying to get rid of both the one I removed and the one I just added but wasn't showing under the Edit Container page disappeared from the Volume Mappings column on the Docker Containers page. Very weird.

     

    my-Sonarr.xml

    Link to comment

    @Squid any ideas?  I have been unsuccessful trying to create this bug.  Curious if this is something caused by a schema change at one point.

    Link to comment
    16 minutes ago, jonp said:

    @Squid any ideas?  I have been unsuccessful trying to create this bug.  Curious if this is something caused by a schema change at one point.

    This could be possible (at least from my uneducated standpoint), this container has existed through a bunch of UnRAID updates, basically since Docker support was added. If it comes to it I can probably remove the container completely and rebuild it, but it seems like it should work properly anyway.

     

    I have tried adding and removing Host Paths to other containers and it works properly, so it seems stuck specifically on this one. The permissions for the xml file for this container is also the same as all others, so it's not like it became read-only at some point.

    Link to comment
    2 hours ago, Squid said:

    Is there another my-Sonarr.xml in there?  Like my-Sonarr (1).xml?

    Yup, there is. I didn't notice it before because it sorts to the end of the directory list. Looking at the settings in there they appear to be "correct", without the Host Path I've been trying to remove.

     

    Would the best action at this point to remove the secondary (my-sonarr (1).xml) or replace the "incorrect" one with the "correct" one?

    Link to comment

    Ok, so I did a bit more experimentation and here is what I found:

     

    The container seems to only read from "my-Sonarr.xml" and only write to "my-sonarr (1).xml". If I delete "my-Sonarr.xml" and go to edit the container, all the fields are empty. If I delete "my-sonarr (1).xml" and go to edit the container, all the settings (including the Host Path I am trying to remove) are there. If I remove the host path and apply the changes to the container again then the "my-sonarr (1).xml" file is recreated but the Host Path is still shown under the Edit Container page. I haven't yet tried removing the container completely and rebuilding it, and at this point I'm not convinced that would even work.

    Link to comment

    Rename "my-sonarr (1).xml" which is the file with the correct content to "my-sonarr.xml".

    Delete the container and recreate it using the just renamed XML file.

     

    Link to comment
    9 minutes ago, bonienl said:

    Rename "my-sonarr (1).xml" which is the file with the correct content to "my-sonarr.xml".

    Delete the container and recreate it using the just renamed XML file.

     

    I did the deletion test already, although I renamed the file "my-Sonarr.xml" to replace the one with the incorrect data. When I tried adding a new Host Path a *new* "my-sonarr (1).xml" file was created and I ended up with the same inability to alter the container, just now with "correct" data. While it fixes this specific issue it will come up again if I ever need to change the Host Paths in the future, so not really a fix. The container still seems to only write to "my-sonarr (1).xml" and read from "my-Sonarr.xml", regardless of the data in the files.

     

    I have not yet tried just deleting the container and the associated templates and starting again from scratch because I thought it might be more useful for the devs to be able to track down the actual issue in case it is causing other underlying problems that I just haven't noticed yet. @Squid did ask about the "my-sonarr (1).xml" file in the first place, so I'm guessing I'm not the first person this has happened to.

    Link to comment
    3 hours ago, IceNine451 said:

    so I'm guessing I'm not the first person this has happened to.

    Not at all.  Rather, if there is another one in there, I am curious if dockerMan was getting confused as to which one it was dealing with.  IE: I downloaded and installed sonarr using your template, and was completely unable to replicate the problem.

     

    4 hours ago, IceNine451 said:

    The container seems to only read from "my-Sonarr.xml" and only write to "my-sonarr (1).xml". If I delete "my-Sonarr.xml" and go to edit the container, all the fields are empty. If I delete "my-sonarr (1).xml" and go to edit the container, all the settings (including the Host Path I am trying to remove) are there. If I remove the host path and apply the changes to the container again then the "my-sonarr (1).xml"

    The reason why is because my-Sonarr.xml isn't the actual name of the container.  According to the xml you posted, the name of the container is sonarr (lowercase).  Due to an edge case scenario a couple of revs ago I submitted a code change to dockerMan to handle filename collisions on the boot drive (which is FAT32) which makes no differentiation between my-Sonarr.xml and my-sonarr.xml  hence it began to add a (1) to it.  IE: the name of the container dictates the filename.

     

    You *may* be running into a weird little edge case with this, but I still can't replicate the problem.

    • Like 1
    Link to comment
    22 hours ago, bonienl said:

    Can you post a screenshot of your sonarr container settings page.

     

    Let me know if you need to see anything else.

    Sonarr.PNG

    Link to comment
    19 hours ago, Squid said:

    Not at all.  Rather, if there is another one in there, I am curious if dockerMan was getting confused as to which one it was dealing with.  IE: I downloaded and installed sonarr using your template, and was completely unable to replicate the problem.

     

    The reason why is because my-Sonarr.xml isn't the actual name of the container.  According to the xml you posted, the name of the container is sonarr (lowercase).  Due to an edge case scenario a couple of revs ago I submitted a code change to dockerMan to handle filename collisions on the boot drive (which is FAT32) which makes no differentiation between my-Sonarr.xml and my-sonarr.xml  hence it began to add a (1) to it.  IE: the name of the container dictates the filename.

     

    You *may* be running into a weird little edge case with this, but I still can't replicate the problem.

    I don't remember for sure, but I feel like at some point in the past I changed the repository for that container without fully rebuilding the config, and it's possible there was a case change that I didn't even think about at the time. That could explain it I guess. And it does seem like dockerMan is getting confused between the files, where when I make changes to the container it will write them to the lowercase-named file but when I update the container it reads settings from the uppercase-named file. I'm guessing I can resolve it myself by either removing the uppercase-named file and renaming the lowercase on so there is only a "my-sonarr.xml" left, or by removing all the templates and starting from scratch. I just wanted to bring the issue up in case it is causing other people different issues or ones I have and don't notice. It's not like I edit host paths on containers every day, but it was annoying to have to remove an empty share that was created every time I updated this container.

    Link to comment
    20 hours ago, Squid said:

    but I still can't replicate the problem.

    The problem occurs when the capitalization of a container name changes. E.g. Sonarr --> sonarr

    At this point the file is saved as "my-sonarr (1).xml" and the link between file (settings) and container is lost, because the container expects to read from "my-sonarr.xml".

     

    I can't remember exactly what your change solved, but it requires some rethinking.

    Link to comment
    43 minutes ago, bonienl said:

    The problem occurs when the capitalization of a container name changes. E.g. Sonarr --> sonarr

    At this point the file is saved as "my-sonarr (1).xml" and the link between file (settings) and container is lost, because the container expects to read from "my-sonarr.xml".

     

    I can't remember exactly what your change solved, but it requires some rethinking.

    I'll retest, but iirc dockerMan did keep track of the change of the filename.  That being said, it was an edge case it solved.  Mainly because of the multiple apps called Plex Media Server where users would up installing incorrect versions of what they wanted simply because of FAT32 naming conventions

    Link to comment

    Still can't replicate it, no matter what I've done, dockerMan is keeping track of the adjusted filename, and picking up the correct xml in the URL always

    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.