Running UnRaid 6.8.3. I have docker containers that I don't want accessible outside of a reverse proxy. So I edited the container and removed the PORTs specified. Everything works fine til I go in and "Check for Updates" followed by "Apply Update". Then the PORTs I removed will be readded to the container's spec. I thought this was just checking the docker repository for a new image. Is this doing something more with checking the templates in "Community Applications" or something? Thanks for the help!

It's by design from the OS.  It assumes that any ports etc that aren't defined in your template are new to the update and adds them in.

 

Is it a particular issue for you, or just an annoyance.

 

If it's an issue for the container itself adding them back in, then you can post in the applicable support thread for the app to have them modify the template accordingly to avoid this behaviour (there is a way for them to not have this happen)

 

If it's an annoyance / problem just for you, then stop the docker service (Settings), switch to advanced view and enable template authoring mode.  Restart the service and edit the app, switch to advanced view and remove the entry TemplateURL

29 minutes ago, Squid said:

If it's an annoyance / problem just for you, then stop the docker service (Settings), switch to advanced view and enable template authoring mode.  Restart the service and edit the app, switch to advanced view and remove the entry TemplateURL

It is definitely just an annoyance to me as I don't want the ports to show back up as then they could be accessed from outside the reverse proxy. So I will try this method. Thanks!

So I turned on Template Authoring in the settings and re-enabled docker. But when I go to edit a container's spec, in advanced mode, I don't see any TemplateURL variables. Below is a snippet of the linuxserver/plex template in advanced mode. "VERSION" is the start of the container's variables.

Phoque.  Yeah, it is removed from the UI.  (I keep forgetting that it is, and even worse I keep forgetting that I'm the one who removed it  )

 

Edit the file /config/plugins/dockerMan/templates-user/my-whateverNameOfTheContainer.xml on the flash drive and remove that line altogether.

Removed the TemplateURL fields from the applicable docker configs. Seems to be working now. Thanks!

On 5/23/2020 at 10:59 PM, Squid said:

Phoque.  Yeah, it is removed from the UI.  (I keep forgetting that it is, and even worse I keep forgetting that I'm the one who removed it  )

 

Edit the file /config/plugins/dockerMan/templates-user/my-whateverNameOfTheContainer.xml on the flash drive and remove that line altogether.

Could I ask why?

Because vast majority of template authors filled it out incorrectly.  So I simply said screw it and CA is going to fill it out automatically for everyone instead.

On 5/22/2020 at 10:16 AM, Squid said:

If it's an issue for the container itself adding them back in, then you can post in the applicable support thread for the app to have them modify the template accordingly to avoid this behaviour (there is a way for them to not have this happen)

 

@Squid Any chance you could detail the changes that must be made to the templates to avoid ports to be re-added on update? Is it only to set the required field to false? Thanks!

7 hours ago, SimonC said:

 

@Squid Any chance you could detail the changes that must be made to the templates to avoid ports to be re-added on update? Is it only to set the required field to false? Thanks!

 

On 1/21/2021 at 12:54 AM, Squid said:

 

The only time <TemplateURL> is left alone is if it is

<TemplateURL>false</TemplateURL>

This is a special circumstance used in a template where the author feels that it is undesirable behaviour that when an update is issued to the container that any ports present in the template that are missing in the user's installation are added back in on the user's installation.  (IE: the template won't get updated if/when the container gets updated)

 

Hello Everyone,

i also got trouble with the TemplateURL behaviour, where some of my dockers could not start due my port assignments. Especially heimdall that by default wanted to listen to port 80, 443/tcp, but i already had swag listening to these ports.

 

its no issue for me editing the necessary xml files. However i observed that the apps that behaved the way i expected them to (honour my local configuration) had the TemplateURL defined in the xml file, just like the ones that "misbehaved" and decided to write this here for reference.

 

For example:

Organizr app, never created any issues for me re-adding ports i did not want, and uses this xml template

https://raw.githubusercontent.com/Organizr/docker-organizr/master/organizr.xml

 

Inside this template i saw:

 

<Config Name="WebUI" Target="80" Default="" Mode="tcp" Description="Container Port: 80" Type="Port" Display="always" Required="false" Mask="false"/>

 

I noticed that on the WebUI config the default port is empty and set as not required. On the other hand, heimdall the misbehaving app, had the default ports set to 80,443 and set as required

 

<Config Name="WebUI" Target="80" Default="80" Mode="tcp" Description="http gui" Type="Port" Display="always" Required="true" Mask="false"/>
<Config Name="Port: 443" Target="443" Default="443" Mode="tcp" Description="https gui" Type="Port" Display="always" Required="true" Mask="false"/>

 

Clearly, this is the template's author decision to honour the local configuration of the app, and there is nothing wrong with Unraid's behaviour. Having said that, if i for example removed the required and default assignments in template authoring mode, what would this count as an alternative workaround on removing the template url from xml file?

 

Nice.  Don't think anyone has ever looked at it that closely.  The "required" though is designed so that if it's there when adding / editing the template the OS insists on having that entry filled out unless you delete the entry.

 

Either way we're seeing which behaviour is better starting on the next rev -> update or not