This plugin does a quick patch to the docker system on 6.12.8 only to prevent any empty host paths or container paths which may be present in an already installed template (or on a new installation) from triggering an error (and creating an orphan image) when updating the application.

 

This is NOT fixing any bug in Unraid at all.  Previously, the docker run command (eg: on 6.12.6) would not return an error if there was no container path specified.  The docker system in 6.12.8+ does return an error (which is the proper operation).  This quick patch simply has the docker system not add in to the docker run command any paths which has either the container or host side of it blank.

 

If you did update an application and then had it orphan due to an empty path, then simply installing this plugin and then going to Apps, Previous Apps and reinstalling will get you back and running without changing the template to how it should be set up

Thank you!   Thank you!    This fixed a tailscale problem.  

 

Prior to the patch, tailscale was removed on update due to the error.

Fortunately Unraid keeps the previous template, so reinstall worked easily.

 

-- Tom

 

I guess a restart is required after installing the plugin right?

My question was more general, is a reboot requiered after the install of the plugin?

1 minute ago, Civic1201 said:

My question was more general, is a reboot requiered after the install of the plugin?

no

34 minutes ago, lawrence1986 said:

I install this patch

This plugin has nothing to do with any other settings etc you may have.   I've moved your posts (and itimpi's) to here 

 

 

I have the "Problem" that are the Borgserver Docker Container sometimes disappear on 6.12.6. It this the same Issue that this Patch are fixed on 6.12.8?

 

I reinstalled the Docker Container again after I see this are disappear.

IDK. What this plugin very slightly changes on 6.12.8 isn't needed on earlier OS versions

I have not had any problems with Dockers since upgrading however Fix Common Problems is recommending to install this patch anyway. Is it something you recommend installing 'just in case'?

1 hour ago, xreyuk said:

I have not had any problems with Dockers since upgrading however Fix Common Problems is recommending to install this patch anyway. Is it something you recommend installing 'just in case'?

I would not bother unless you have problems with docker containers which are incorrectly configured and exhibit the symptoms this plugin helps hide.

5 hours ago, itimpi said:

I would not bother unless you have problems with docker containers which are incorrectly configured and exhibit the symptoms this plugin helps hide.

 

I did install it as I saw your post on the 6.12.8 announcement thread. Though I had 0 issues with any dockers. Worth uninstalling or worth keeping it for the future when spinning new dockers?

Keeping.  Doesn't affect anything

Cant seem to find this plugin in app section 

If it's not there you're not running 6.12.8

On 2/18/2024 at 4:24 AM, Squid said:

This plugin does a quick patch to the docker system on 6.12.8 only to prevent any empty host paths or container paths which may be present in an already installed template (or on a new installation) from triggering an error (and creating an orphan image) when updating the application.

 

Are you able to clarify exactly what this means.

It it in the Docker containers advanced settings, the paths, variables, ports, etc, if there's fields defined and present but with no value in them?

If thats the case, is it resolvable by defining or deleting those instead of installing the plugin?

If we want to keep those around, is it possible to install the plugin before upgrading so things don't break?

No.  ANY path that would look akin to this

 

It's empty.  Seems like a lot of users have left paths (which were unused by them) blank instead of hitting "Remove"

 

<6.12.8 docker itself ignored it.  6.12.8+ Docker returns an error (IMO rightfully so).

 

Trouble is that if you've done that without this patch on 6.12.8 when you simply update the container it will return an error,  become an orphan, and require a reinstall from Apps, Previous Apps and you to find the empty path and remove it.  I figured the patch would save everyone a ton of hair by ignoring empty paths when the docker run command gets created.

 

As said, it's not a bug in the OS.  I'm just making things work the way they used to for this one thing.  I figured that if one of the LT devs winds up asking me WTF happened here (and some users before the patch), it would wind up becoming a nightmare and a one line change solves it.

Good Lord, Thank you!
I thought I couldn't get FileBot reinstalled.

But while this may not be a bug, this patch should be included in Unraid by default.

8 hours ago, user-115 said:

But while this may not be a bug, this patch should be included in Unraid by default.

Personally I disagree with that as I am not happy with anything that hides genuine errors when they can easily be fixed.

8 hours ago, user-115 said:

But while this may not be a bug, this patch should be included in Unraid by default.

In my oppinion it‘s up to the maintainer to mark a path as required in the template which is empty to force the user to either specify a path or remove the path from the template.

 

The same applies to devices that may be empty in the template, they should be also be marked by the maintainer from the template as required so that the user is, again, forced to fill it out or remove the device entry.

This plugins behavior should be the default imo

Otherwise, non required paths are pointless (and i personally like them as I don't need to lookup the path again if i decide to use it in the future, not to mention the potentially missing comment/instruction)

Edited February 22, 20241 yr by Alintya

49 minutes ago, Alintya said:

This plugins behavior should be the default imo

Otherwise, non required paths are pointless (and i personally like them as I don't need to lookup the path again if i decide to use it in the future, not to mention the potentially missing comment/instruction)

All future releases of the OS have the same code patch included

On 2/21/2024 at 8:58 AM, ich777 said:

In my oppinion it‘s up to the maintainer to mark a path as required in the template which is empty to force the user to either specify a path or remove the path from the template.

Sure.  No argument per se on that one.  But, the point of this patch was to remove the support requests from how the docker executable handled things since 2015 vs today, and based upon at least one person who surprised me by getting caught by it is likely a widespread configuration mistake.  And the effects of what docker changed also happens on an update resulting in an orphaned container.

 

Or to put it another way, the point of the patch isn't to make the user's life easier, but rather everyone else who has to continually answer the posts about this that will go on and on and on.   The user's life being easier is simply a nice side effect...  

On 2/21/2024 at 8:58 AM, ich777 said:

The same applies to devices

Did 6.12.6 not fail when the template referenced a non-existent device (eg: /dev/dri15?)

27 minutes ago, Squid said:

Did 6.12.6 not fail when the template referenced a non-existent device (eg: /dev/dri15?)

I'm not sure anymore, I know for sure back then when I had my Jellyfin template in the CA App that I needed to mark it as required because you could actually create the container without issues.

 

29 minutes ago, Squid said:

But, the point of this patch was to remove the support requests

Sure, I'll agree on that. No worries.

I've read the above. I still don't understand why this is even required. Responses above have said that this isn't a bug in .8. Yet, this "patch" exists as a thing in our collective universe.  Either this "patch" should be included in UnRAID's base code and a .9 release addresses this, or I should uninstall "Fix Common Problems" / tell it to ignore this issue.

 

I completely understand and appreciate that none of the above is part of the UnRAID native operating environment, but I also shouldn't be getting nightly reminders that I require a "patch" for something that doesn't impact me at all. And if I install it to quiet my alerts, I then have to remember to uninstall it when it isn't an issue.

1 hour ago, jaylo123 said:

I've read the above. I still don't understand why this is even required. Responses above have said that this isn't a bug in .8. Yet, this "patch" exists as a thing in our collective universe.  Either this "patch" should be included in UnRAID's base code and a .9 release addresses this, or I should uninstall "Fix Common Problems" / tell it to ignore this issue.

 

I completely understand and appreciate that none of the above is part of the UnRAID native operating environment, but I also shouldn't be getting nightly reminders that I require a "patch" for something that doesn't impact me at all. And if I install it to quiet my alerts, I then have to remember to uninstall it when it isn't an issue.

 

The purpose of the patch is to get around the fact that certain types of errors in Docker templates used to silently get ignored, and with 6.12.8 if you have them the docker container can fail to start.  There seem to be many users with this issue on frequently used containers so this plugin was created to get back the old behaviour to reduce support load.  

 

If you have no containers that have this issue then you can simply tell Fix Common Problems to ignore it.