Squid

Thanks, managed to access the Web GUI in Bridge mode but couldn't in Host mode. When I access the WebGUI, under 'Server Network Settings' I see "eth0: 172.17.0.2" Should this match my internal IP range or external IP? as it does not match either. Also I have a bridge setup in UnRAID (br0) should I be using that instead of eth0? In short No, and default is for the Network Settings within OPenVPN-AS using this container to be (in this case this is my Backup Server who's IP address is 192.168.1.3): eth0: 192.168.1.3 As for an explanation, I shall do my best to explain as I understand it. No this is the "internal" IP of the Container. Note that you access this on the "unRAID Server" via its IP or hostname. E.g.: Container = 172.17.0.2:port# => unRAID machine = 192.168.1.1:port# AFAIK the port(s) in use by the container is usually static (in some cases changeable like OpenVPN-AS) but the port on the unRAID machine is variable. Note also that some Containers HAVE to run in Host or Bridge mode for them to work. Anyway, in general IF you select the Container to run in Host mode then you are essentially saying to Docker => please map the Container Port to my unRAID Server port. This can be a hassle IF you have more than one Container wanting the same port(s). This is where Bridge mode comes in. This is where docker differs from a VM for instance. It means that docker still uses the unRAID Server IP address, but that there is a mapping (bridge) between the ports as seen inside the docker container, and the ports these are mapped to at the unRAID Server level. This is how you can have two different docker containers think they are using the same port internally, but that they are seen as different ports on the unRAID Server. I hope that makes some sense to you. Sounds like a candidate for the Docker FAQ

The wrong one Thanks, that's all I needed. Yeah, a month or so ago CA needed to be updated to handle a change in CP

what version of CA?

What if just the stickers are made in China? Fixed: Customized templates (based upon one from the application feed) were being incorrectly tagged as being incompatible Enhanced: Reminder to update CA if update available* * Myself, just like everyone else probably don't continually update plugins if I don't use them on a day to day basis. Unfortunately, the next time that I go to use whatever plugin, I've probably already forgotten that there was an update available. (And, I get sick whenever I look at user's diagnostics and wonder WTH they are still running a version of CA a couple of months out of date) If the dynamix plugin manager has found an update available to CA, then a little note at the bottom of CA's screen will appear suggesting to update the plugin.

Able to replicate now.... There's nothing incompatible with the app itself. The issue here is that you've changed the name of the app from plex to Plex. I'll pump out an update to CA to address. Sorry for the inconvenience

What's the output of cat /etc/unraid-version What version of community applications is currently installed? unRaid version 6.1.9 Community Application version 2016.03.04 update CA Steps taken: 1. Update Applications - did not work 2. Uninstall/Reinstalled CA, then Update Applications - did not work 3. Stopped Array, rebooted server, updated application - still did not work Even with the message, there is no problem with the app; CA will let you install when Hide Incompatible Apps is set to no. (By "did not work", I am assuming the incompatible message is still there -> since I'm not following whatever else is going on here) But, since I can't replicate this (and no one else is reporting a similar issue), I need to know what the output is of cat /etc/unraid-version And additionally, when you hit "Default" on the container, the browser URL is going to display a path to the template. (Something like http://server_a/AddContainer?xmlTemplate=default:/var/lib/docker/unraid/templates-community-apps/221.xml) Can you also post the output of: cat whatever the path is in bold above

What's the output of cat /etc/unraid-version What version of community applications is currently installed? unRaid version 6.1.9 Community Application version 2016.03.04 update CA

When you hit Default, on the resulting page (just don't hit create / update and you won't lose anything), there's a URL? What's the URL?

What's the output of cat /etc/unraid-version What version of community applications is currently installed?

Behind a vpn by chance? Try hitting update applications

Try Settings - Network Settings - and set DNS addresses of 8.8.8.8 and 8.8.4.4 and then try again

In host mode you never see port mappings as the app has access to any port as it sees fit

But the net result is the same. Presumably since its /data OP was migrated from binhex apps or is still using them

How do you figure? The /data doesn't match in sonarr as to the other two. The way that you've got it set up is that presumably sab is saving its downloads into its /config folder (appdata/sabnzbd/downloads/complete) Here's what happens when the docker containers try and communicate to each other. Sonarr / CP tells sab to download something. Scenario #1: If sab downloads into its /config/Downloads/complete/CATEGORY folder: Sab downloads it and stores it into its /config/Downloads/complete/CATEGORY folder Sab then tells Sonarr / CP that the download is completed and passes the path of the file back to sonarr / CP. This path is going to be /config/Downloads/complete/CATEGORY/whatever filename (Note that this maps out to the host as /mnt/user/appdata/sabnzbd/Downloads....) Sonarr / CP look in /config for that file and can't find it (because they are looking for the download in /mnt/user/appdata/sonarr/Downloads/completed/....) Net result: failure Scenario #2: Sab is downloading into /data Sonarr tells sab to download. Sab does and passes the path back to sonarr. Sab in this case tells sonarr that the file is stored in /data/downloads/Complete/TV/whatever file name (This maps out to /mnt/user/downloads/complete/tv/.....) Sonarr looks at that path and tries to process the file and it fails. Because according to the /data mount your passing to sonarr, it is actually looking for the file in: /mnt/cache/sabnzbd/Downloads/Complete/TV/downloads/Complete/TV/whatever filename Net result: failure The Fix set sab to download to /data set the mount points for all the apps that have to deal with the downloads (ie: CP, Sonarr, Sab) to be identical Net result: success The logs from Sonarr when it fails to move will tell the complete story

Then either you've messed up the path's in the docker, or you've got drone factory enabled in sonarr.

First thing, is you want to make sure that the /data mapping matches on all containers (and it doesn't on CP) Secondly, Sab is putting everything into Downloads/complete (and if you look above, you'll see that relative folders are based upon /Config) (and sonarr does not have access to that particular folder) You want to tell Sab to put everything into /Data Once Sab stores its completed downloads in /Data (and all three containers have the same mappings for /Data), then everything should work perfectly (if the API keys match correctly too). You won't even need to use the Black Hole on CP either

Make all the users only have read only access. Create another user that has rw access. Login with you client to that new user when ever you need to write a file (if that's doable). Otherwise then you have to switch the share settings on the fly. As an aside, make certain users only have read-only access permanently to the shares. In my house pretty much every share is read-only for everyone, but I am the only one who permanently has rw access. Not particularily worried about ransomware, but more about people inadvertently deleting media Also, don't ever map shares to drives. Most virus / ransomware aren't going to be scanning your network, but are going to be scanning your local drives (of which for all intents and purposes a mapped share appears to be)

When I die I want to go peacefully in my sleep like my grandfather, not yelling and screaming like the passengers in his car did - Fixed: readmore on searches (regression error) - Fixed: private repositories (dockerHub searches) were being saved into wrong folder (regression error) - Enhanced: Update Applications (or reversion to legacy mode) will not fail if a single repository fails to download - Enhanced: Now include cAdvisor XML template so as to not rely upon smdion's repository - Enhanced: Popup descriptions now include links to go to cAdvisor's page for running docker applications - Enhanced: Templates passed through to dockerMan are now Moderated to allow CA to fix any errors, typos, etc in the author's template - Enhanced: Major overhaul of the XML template generation* - Enhanced: Continuing code cleanup * CA now has the ability to send version 2.0 (unRaid 6.2) xml templates to dockerMan, with the additional features that 6.2 offers. Currently however, the application feed does not correctly parse the additional entries for 6.2. Once this is working correctly, another update will be pushed to enable this feature. Alongside with this (and currently enabled) is the templates passed through to dockerMan have the ability to now be moderated by CA to fix any major issues, etc should the template maintainer go AWOL.

Your wish is my command !

You can issue a PR with a new xml to me, but I'd rather you fork it then I don't have to worry about it. And, you're not alone in missing the PMs. A few other authors missed them also. Although technically you don't have to do anything other than add the appropriate XML's to an existing repo you have.

There are currently two versions of preclear: one that is the current stable version and has a version number of 2015.11.18 and a testing beta version released today. The first one use Joe L. script to preclear; the new one uses a new script I wrote, but still on beta. I hope you realize that for CA to display the beta version, you're going to have to fork the plugin repo (sent you a PM a while back) https://github.com/Squidly271/gfjardims-plugin-repository/ (should probably do it anyways as you can then take advantage of what CA offers)

plugins - check for updates - install the webUI update that'll be available Odds on, you've got a space in one of your volume mounts. the update will fix it

Yup... That's it... Now someone else familiar with rutorrent can help you out.

Long standing bug with dockerMan where it doesn't pick up changes to the webUI after an app is initially installed. My fail safe solution here is to delete the docker.img and restart the server, then redownload all of your apps again using the my* templates (or CA's previous apps tab), but if anyone has a better idea, I'm all ears....