Squid

By plugin's, do you mean Plugins or Docker Applications? If docker Applications, then you have to stop and start the entire docker service in order for any apps to see any mountings that UD performs (6.1.x) If you're under 6.2, then you can modify your volume mountings to use the new "slave" option which should fix this up for you.

Tons and tons of errors on the loop0 device (docker.img) You can try a scrub from within docker settings, but your best course of action may be to just delete the image file, then recreate it, then add all of your apps back in via CA's previous apps section (all your old mappings and ports will be already prefilled out for you) If that still doesn't get you anywhere, then I'd create a new thread in General Support (v6) so that many eyes will have a look at this. (I'm at work currently and am not always able to put the time in for unRaid problems - especially analysis of syslogs)

You haven't had to click that button since June 2015. (Part of the reason it says "Don't Click Me - Why Are You Clicking Me?" on its pop up) Unless you're talking about Plugins - Check For Updates, in which case, yes you will now have lots of spare time on your hands to spend with your better-half. Hmmm, well in that case I would like a feature request to blow up the auto update feature into oblivion... The better-half always has something for me to accomplish [emoji51] Don't enable it, and tell her that it's all my fault that you can't spend any time with her

You haven't had to click that button since June 2015. (Part of the reason it says "Don't Click Me - Why Are You Clicking Me?" on its pop up) Unless you're talking about Plugins - Check For Updates, in which case, yes you will now have lots of spare time on your hands to spend with your better-half.

Whatever disk your docker.img file is mounted on has some corruption (or the docker.img file is totally corrupted) and has been mounted as read-only. Probably your best course of action is to ssh into your server and issue a diagnostics command, which will save your diagnostics to your flash drive. The webUI is going to stay unavailable as for whatever reason, unRaid is continually trying to delete a file and failing, so to recover you're probably going to have to also issue a powerdown -r command to recover. Then don't go into CA again until someone checks out your logs

When you add or edit a container after you say create or add or whatever it says it brings up a new screen with the download progress and the docker run commAnd at the bottom. Need to see a screen shot of the command and its result Sent from my LG-D852 using Tapatalk

Edit sonarr then post a screenshot of what appears. Including the docker run command Sent from my LG-D852 using Tapatalk

So up around the head, down the back until you hit your ??

But the question still remains: Enquiring minds want to know.

LOL Too bad our friend hasn't piped in yet. I bet he would have an answer Sent from my LG-D852 using Tapatalk

When bald people wash their face, how far up do they go? Added: Ability to auto update selected plugins (after all, everything else in the world autoupdates - why not unRaid?) A new icon will now appear within the Community Applications section of unRaid's settings tab. "Auto Update Settings" This will allow you to select which plugins you would like to keep always updated with the current version without any user intervention. I think the usage of the module is pretty self explanatory, but full help text is available on it (and the manual has also been updated) One prerequisite is that under Settings - Notification Settings, you must have dynamix set to check for plugin updates (I would recommend daily). It shouldn't matter if you have browser / email / agent notifications set up or not. Note that if you have browser notifications enabled, you will still wind up having to acknowledge that notification as I do not believe it is possible (but willing to be proven wrong) for CA to cancel a browser notification automatically. This module will not (and will never) automatically update the unRaid OS It will however automatically update the webGUI if you allow it to. The actual updates are installed according to the daily fixed schedule (adjustable via Dynamix Fixed Schedules plugin available within CA) Because of some outstanding issues with dockerMan determining when updates are available for docker applications, this module will not support docker apps until those issues are resolved. http://i46.photobucket.com/albums/f109/squidaz/Untitled_zpsi06ibcgh.png[/img]

Chewing the percocets or t3's will solve that problem

Just edit the go file and add the following to it. chown nobody:nobody /tmp/emby Then when the system boots up it will perform that action on the folder eliminating the need to go in each time and reboot. In addition, it is worth noting that you should keep an eye on what you put into the go file as when you upgrade to future versions it can have impacting effects. I always restore my default go file before upgrading, upgrade then re-apply. folder doesn't exist until the docker restarts and without wait commands in go prior to issuing the chown, the command will fail. Hence why my linked post has a mkdir -p /tmp/emby in it first Ah, now I get it. Couldn't he just create it from the go file too and set the permissions? yeah.... This can be corrected in the Go file so it "appears" to be persistent on reboot. Sorry for being obtuse, I still consider myself an "end user" making my way towards "power-user." Can you, or someone in the community, point me to either the Go file, or to the link of documentation which outlines the Go file (so I can RTFM)? I'm assuming the go file is something other then rc.d scripts? /config/go on your flash drive (/boot/config/go) Standard bash script. I guess you would wind up adding these commands to it mkdir -p /tmp/emby chown nobody:nobody /tmp/emby

Just edit the go file and add the following to it. chown nobody:nobody /tmp/emby Then when the system boots up it will perform that action on the folder eliminating the need to go in each time and reboot. In addition, it is worth noting that you should keep an eye on what you put into the go file as when you upgrade to future versions it can have impacting effects. I always restore my default go file before upgrading, upgrade then re-apply. folder doesn't exist until the docker restarts and without wait commands in go prior to issuing the chown, the command will fail. Hence why my linked post has a mkdir -p /tmp/emby in it first

no

/tmp/emby does not stay on reboot. Rather its recreated at the time of the emby docker restarting. And after its created is when you'd have to do the chown. Hence why I'm suggesting to create the folder first. Otherwise the chown in go will do nothing, because the folder doesn't exist at that point.

Thank you sir. Actually all that I need is line-2; if I'm remembering what occurs correctly (it's been a month since my last reboot). You'll need them both, because without the mkdir, when it hits the chown it will error out if the directory isn't already made (and since emhttp starts in the background and whenever it gets around to it starts up the docker apps, the odds are really against the directory existing no matter where you put the chown in the go file unless you add appropriate waits.

This can be corrected in the Go file so it "appears" to be persistent on reboot. Sorry for being obtuse, I still consider myself an "end user" making my way towards "power-user." Can you, or someone in the community, point me to either the Go file, or to the link of documentation which outlines the Go file (so I can RTFM)? I'm assuming the go file is something other then rc.d scripts? /config/go on your flash drive (/boot/config/go) Standard bash script. I guess you would wind up adding these commands to it mkdir -p /tmp/emby chown nobody:nobody /tmp/emby

Oh and BTW, while CA did happen to go down this morning because of the changes you happened to have made, it wasn't because of this error in particular. Rather it was because of how the appFeed happened to handle your template with only a single <Config> entry (and if that problem didn't happen this morning, it would have eventually happened with another template that was perfectly formed v2)

You should be able to do that via appending the tag to the Repository<Repository>homeassistant/home-assistant-dev:dev</Repository> With no tag present, docker automatically appends :latest (not sure if anyone has this in their templates, but it should work - if not, then its another bug report) Unless you're talking about dockerMan / CA automatically appending something based upon some other criteria in the template

I know... I'm a PITA (or the whole attribute thing is a PITA)

Instead of doing that, what I personally would have done is instead redo the template via Save Template on 6.2 and copy the whole thing. The only thing in particular that was missing from the template as it stood was <Container Version="2"> at the top, but the net result with the comment would have been the same. The Config section is ignored under 6.0 / 6.1 and is only relevant under 6.2, but I think its a bug in dockerMan in how it processed the template (http://lime-technology.com/forum/index.php?topic=48193.msg464758#msg464758), and 6.2 does allow some neat things in paths / ports like hiding the ones that can't change, obfuscating passwords, etc.

Nothing like a problem to wake you up on Saturday morning. Beats coffee any day.

I see that you've updated your templates to take advantage of some of the new features in 6.2 However, it appears that you've cut and pasted the extra lines into the existing template. Unfortunately, that does not work as there are some items which are missing (notably the Version attribute) Instead of cutting and pasting, what you should do is copy the entire template that 6.2 shows you and replace the entire file, otherwise what you get is a duplicated /config section which will probably mess things up should the user decide to change the appdata path (and not hit advanced settings and change the other /config path that appears there) tldr: Anyone adding this app under 6.2 before the template gets updated: If you change the appdata path, you should also hit Show Advanced Settings, and make sure that the path there matches exactly, otherwise strange things will probably happen. Beyond that, I really have no idea if the template even works properly because duplicated /config paths get passed through to the container. While it does appear to work, I am in no position to test this properly.