[SOLVED] 6.2 dockerMan overwriting user templates /config host volume


Recommended Posts

unRAID OS Version:

6.2 Beta 19

Description:

When installing a user-template (and the container isn't already installed), dockerMan is overwriting the user-template's host volume mapping for /config

How to reproduce:

Set up a container with a host mapping for /config with something OTHER than what dockerMan populates it with ( or install a user-template that you have not installed yet on 6.2, but was created on 6.1 with a mapping that doesn't quite match what 6.2 suggests)

Expected results:

The host mapping I set originally should be persistent, and should NOT be modified by dockerMan in any way shape or form

Actual results:

Its not

Other information:

 

While I understand the reasoning behind automatically overwriting /config host mapping, in practice this is the wrong idea if the mapping is from a user-template.

 

This logic error effectively removes ones of the big advantages of docker on unRaid, where you can delete the docker.img at will and then recreate it, add all of your user templates back in and be back up and running.

 

While its not an issue for new containers that have never been installed before on anything other than 6.2, it is a HUGE issue for when you're reinstalling a container that was previously installed on 6.1 since that version did NOT have automatic mappings available to it, and only in rare circumstance will the automatic folder chosen by dockerMan actually match what the user had to manually select on 6.1

 

In my case, after deleting my docker.img to test out another defect report, I proceeded to reinstall all of my containers, only to discover that 90% of the apps did not work afterwards.  When I was just about to go yelling and screaming at lsio over this, when I figured out what was actually happening.

 

This is a big problem that is going to wind up being a support nightmare for everyone on the forums.  (And additionally, the /config folder is only visible while in advanced mode, so most people won't even catch it)

 

 

The real solution here is that host mappings on /config need to be removed by the author at the raw template level, and then only filled out by dockerMan when it is actually blank

Link to comment

Thanks for the defect report Squid!

 

The only time dockerMan will overwrite /config host mapping automatically is when 'default' is prefixed for the xmlTemplate url argument: (e.g. xmlTemplate=default:/path/to/xml_template)

 

If you delete a container (that had a custom /config host path) and install that user-template again dockerMan will not modify your original custom /config host path.  This is because 'user' is prefixed for the xmlTemplate url argument: (e.g. xmlTemplate=user:/path/to/user_template)

 

Now I haven't gone full gangbusters and deleted my docker.img yet but I've confirmed the logic and cases above to work as intended which was integrated at least since Beta18.

 

 

Link to comment

Thanks for the defect report Squid!

 

The only time dockerMan will overwrite /config host mapping automatically is when 'default' is prefixed for the xmlTemplate url argument: (e.g. xmlTemplate=default:/path/to/xml_template)

 

If you delete a container (that had a custom /config host path) and install that user-template again dockerMan will not modify your original custom /config host path.  This is because 'user' is prefixed for the xmlTemplate url argument: (e.g. xmlTemplate=user:/path/to/user_template)

 

Now I haven't gone full gangbusters and deleted my docker.img yet but I've confirmed the logic and cases above to work as intended which was integrated at least since Beta18.

Have to say that you're incorrect there.  Remember that we are talking about user templates created from 6.1 (v1) which is where the majority of users that are going to be running 6.2 are coming from.

 

Here's my user-template for DigiKam (haven't reinstalled it yet on 6.2 as I have no use for it)

<?xml version="1.0" encoding="utf-8"?>
<Container>
  <Name>DigiKam</Name>
  <Description>DigiKam is a docker for the digiKam picture management software [br][br]&#13;
[b][u][span style='color: #E80000;']Configuration[/span][/u][/b][br]&#13;
[b]/config[/b] This is where the digiKam configuration and library files will reside[br]&#13;
[span style='color: #E80000;']8080[/span] is the WebUI port[br][br]&#13;
Don't forget to enter in the host port, config folder and the pictures location. [br][br]&#13;
To access the digiKam GUI, open the WebUI. [span style='color: #E80000;']First time running the WebUI, select /config as the database location.[/span][br]&#13;
Default resolution for the digiKam window is 1280x720. You can change that to any resolution by opening the Advanced View and modifying the HEIGHT and WIDTH variables.[br]&#13;
This docker will install digiKam 4.9.0. If you would like to keep up to date with the latest releases, please set the EDGE variable to 1&#13;
</Description>
  <Registry>https://registry.hub.docker.com/u/aptalca/docker-digikam/</Registry>
  <Repository>aptalca/docker-digikam</Repository>
  <BindTime>true</BindTime>
  <Privileged>false</Privileged>
  <Environment>
    <Variable>
      <Name>WIDTH</Name>
      <Value>1280</Value>
    </Variable>
    <Variable>
      <Name>HEIGHT</Name>
      <Value>720</Value>
    </Variable>
    <Variable>
      <Name>EDGE</Name>
      <Value>0</Value>
    </Variable>
  </Environment>
  <Networking>
    <Mode>bridge</Mode>
    <Publish>
      <Port>
        <HostPort>8084</HostPort>
        <ContainerPort>8080</ContainerPort>
        <Protocol>tcp</Protocol>
      </Port>
    </Publish>
  </Networking>
  <Data>
    <Volume>
      <HostDir>/mnt/cache/appdata/digikam</HostDir>
      <ContainerDir>/config</ContainerDir>
      <Mode>rw</Mode>
    </Volume>
    <Volume>
      <HostDir>/tmp/server_b_pictures</HostDir>
      <ContainerDir>/pictures</ContainerDir>
      <Mode>rw</Mode>
    </Volume>
  </Data>
  <Version>4ad8f8e2</Version>
  <WebUI>http://[iP]:[PORT:8080]/#/client/c/digiKam</WebUI>
  <Banner></Banner>
  <Icon>http://www.h-online.com/imgs/43/6/9/3/5/4/7/Digikam-logo200-22eb510f46d16449.png</Icon>
  <ExtraParams></ExtraParams>
</Container>

Here's what dockerMan decided to do with it (only visible via Advanced Settings):  Notice the very subtle change in the appdata folder.  digikam turned into DigiKam

Untitled_zpsx15exoc1.png

and here is the user template after dockerMan has reinstalled it:

<?xml version="1.0"?>
<Container version="2">
  <Name>DigiKam</Name>
  <Repository>aptalca/docker-digikam</Repository>
  <Registry>https://registry.hub.docker.com/u/aptalca/docker-digikam/</Registry>
  <Network>bridge</Network>
  <Privileged>false</Privileged>
  <Support/>
  <Overview>DigiKam is a docker for the digiKam picture management software [br][br]&#;
[b][u][span style='color: #E80000;']Configuration[/span][/u][/b][br]&#;
[b]/config[/b] This is where the digiKam configuration and library files will reside[br]&#;
[span style='color: #E80000;']8080[/span] is the WebUI port[br][br]&#;
Don't forget to enter in the host port, config folder and the pictures location. [br][br]&#;
To access the digiKam GUI, open the WebUI. [span style='color: #E80000;']First time running the WebUI, select /config as the database location.[/span][br]&#;
Default resolution for the digiKam window is 1280x720. You can change that to any resolution by opening the Advanced View and modifying the HEIGHT and WIDTH variables.[br]&#;
This docker will install digiKam 4.9.0. If you would like to keep up to date with the latest releases, please set the EDGE variable to 1&#;
</Overview>
  <Category/>
  <WebUI>http://[iP]:[PORT:8080]/#/client/c/digiKam</WebUI>
  <Icon>http://www.h-online.com/imgs/43/6/9/3/5/4/7/Digikam-logo200-22eb510f46d16449.png</Icon>
  <ExtraParams/>
  <Description>DigiKam is a docker for the digiKam picture management software [br][br]&#;
[b][u][span style='color: #E80000;']Configuration[/span][/u][/b][br]&#;
[b]/config[/b] This is where the digiKam configuration and library files will reside[br]&#;
[span style='color: #E80000;']8080[/span] is the WebUI port[br][br]&#;
Don't forget to enter in the host port, config folder and the pictures location. [br][br]&#;
To access the digiKam GUI, open the WebUI. [span style='color: #E80000;']First time running the WebUI, select /config as the database location.[/span][br]&#;
Default resolution for the digiKam window is 1280x720. You can change that to any resolution by opening the Advanced View and modifying the HEIGHT and WIDTH variables.[br]&#;
This docker will install digiKam 4.9.0. If you would like to keep up to date with the latest releases, please set the EDGE variable to 1&#;
</Description>
  <Networking>
    <Mode>bridge</Mode>
    <Publish>
      <Port>
        <HostPort>8084</HostPort>
        <ContainerPort>8080</ContainerPort>
        <Protocol>tcp</Protocol>
      </Port>
    </Publish>
  </Networking>
  <Data>
    <Volume>
      <HostDir>/mnt/cache/appdata/DigiKam</HostDir>
      <ContainerDir>/config</ContainerDir>
      <Mode>rw</Mode>
    </Volume>
    <Volume>
      <HostDir>/tmp/server_b_pictures</HostDir>
      <ContainerDir>/pictures</ContainerDir>
      <Mode>rw</Mode>
    </Volume>
  </Data>
  <Environment>
    <Variable>
      <Value>1280</Value>
      <Name>WIDTH</Name>
      <Mode/>
    </Variable>
    <Variable>
      <Value>720</Value>
      <Name>HEIGHT</Name>
      <Mode/>
    </Variable>
    <Variable>
      <Value>0</Value>
      <Name>EDGE</Name>
      <Mode/>
    </Variable>
  </Environment>
  <Config Name="Port 1" Target="8080" Default="8084" Mode="tcp" Description="Container Port: 8080" Type="Port" Display="always" Required="true" Mask="false">8084</Config>
  <Config Name="AppData Config Path" Target="/config" Default="/mnt/cache/appdata/DigiKam" Mode="rw" Description="Container Path: /config" Type="Path" Display="hidden" Required="true" Mask="false">/mnt/cache/appdata/DigiKam</Config>
  <Config Name="Path 2" Target="/pictures" Default="/tmp/server_b_pictures" Mode="rw" Description="Container Path: /pictures" Type="Path" Display="always" Required="true" Mask="false">/tmp/server_b_pictures</Config>
  <Config Name="Variable 1" Target="WIDTH" Default="1280" Mode="" Description="Container Variable: WIDTH" Type="Variable" Display="always" Required="false" Mask="false">1280</Config>
  <Config Name="Variable 2" Target="HEIGHT" Default="720" Mode="" Description="Container Variable: HEIGHT" Type="Variable" Display="always" Required="false" Mask="false">720</Config>
  <Config Name="Variable 3" Target="EDGE" Default="0" Mode="" Description="Container Variable: EDGE" Type="Variable" Display="always" Required="false" Mask="false">0</Config>
</Container>

 

 

The problem is that 99.99% of the user templates out there are v1 and dockerMan isn't honoring what should be the default setting of a host mapping for /config when there is no <Config> section for it.

 

Now DigiKam, I could care less about (only have the user-template for testing purposes).

 

I caught this because dockerMan decided to change my appdata for the following apps as follows (to match the exact name of the container)

 

couchpotato became CouchPotato

mysql became MySQL

nzbdrone became Sonarr

 

and so on.

 

Out of all of my containers, only a single one (plex) happened to have not changed simply because the container's name (plex) happened to have matched exactly the naming for the appdata I made in 6.0

 

The changing of the names (coupled with the fact that /config is hidden within advanced settings) is so subtle that the vast majority of people will miss the change (if they even remember what they called it in the first place or have the wherewithall to look in their appdata folder to see what folders exist there)

 

Just imagine how annoyed you would be when the system is designed to allow you to reinstall an app through user-templates and be back up and running after the download is completed only to discover that their entire SQL database is empty.

 

And with it being such a subtle naming change, it will take forever to diagnose the issue on the forums

 

 

Link to comment

Shouldn't matter if it's a v1 or v2 template, dockerMan won't overwrite /config host path as long as 'xmlTemplate=default' isn't in the browser url.

 

As a test, I took your digikam.xml (v1 user template) and saved it to my server as /boot/config/plugins/dockerMan/templates-user/my-DigiKam.xml

 

Next, Docker -> Add Container -> choose 'my-DigiKam' from Template dropdown.  Turn on Advanced View and /config mapping untouched:

squidy_zps36jdvqiw.png

 

Are you adding user templates a different way?  Does your browser URL differ after the host name?

Link to comment

Are you adding user templates a different way?  Does your browser URL differ after the host name?

ok... I see the issue now.  The URL has changed.  What was particularily throwing me was that even with the very slight difference in the URL, the drop down on the page still recognized that I was using the user-template (by clicking it after the template was loaded, the user template was still highlighted).  And even brings up the icon to allow me to delete the template, since it knows it's a user-template

 

I wouldn't be using a different way of selecting the user template if dockerMan had some sort of clue about how to sort the drop downs, rather than just tossing them all up in the air, seeing how they land, and saying to itself "I think this is the proper way to show them"  8)

 

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
Reply to this topic...

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