Squid

What do the docker logs for Rutorrent show?

Yes that what I wanted to try but how? Edit the docker and change the host port from 80 to something else Sorry if that sounds strange but how do I edit the docker? The rutorrent "/config" directory is empty. Click the icon (on the docker tab), select "Edit" Ok, so removed port 80 and replaced with port 44444, now rutorrent shows the green arrow but when selecting "webui" I return to the unraid main page. Long standing bug in unRaid where dockerMan doesn't pick up changes to the webUI. Easiest solution is to bookmark http://IPADDRESS:44444

Yes that what I wanted to try but how? Edit the docker and change the host port from 80 to something else Sorry if that sounds strange but how do I edit the docker? The rutorrent "/config" directory is empty. Click the icon (on the docker tab), select "Edit"

Yes that what I wanted to try but how? Edit the docker and change the host port from 80 to something else

Not familiar with that container but as a general rule you only ever adjust the host port and leave the container post alone

Hmm. That's strange because someone else is having the same exact issue with the letsencrypt container. It seems like an unraid issue. Which unraid version are you on? Not at my server to check, but I don't think that the trailing / after the port should be there. Good eye, that's the problem. My xmls leave the protocol field blank and the dockerman fills it with tcp. It seems that the new unraid (I'm assuming folks updated to the latest beta) leaves it blank and it causes the issue I'm not on 6.2 yet, but I would call that a bug. dockerMan shouldn't allow you to start installing if a port is present but its type is undefined

Hmm. That's strange because someone else is having the same exact issue with the letsencrypt container. It seems like an unraid issue. Which unraid version are you on? Not at my server to check, but I don't think that the trailing / after the port should be there.

To volume mappings add /mnt mapped to /mnt. Once in dolphin navigate to root then mnt and do what you need to do

As an FYI, if you uninstall an application through CA it will prompt you if you want to delete the appdata folder after the app is uninstalled.

Dunno how useful that's going to be. I would want the ability to check or uncheck specific apps, there are some apps I tried and didn't like. How about the ability to add or remove apps to an installation que? You could go through and pick what you wanted (add to cart) and when you are done choosing, start the bulk installation (checkout). Apps installed this way should be set not to immediately start on install, so you can go through and edit settings, or if a local template exists, preload it. That is what it does now one at a time - a check option to just do it with current template settings would be nice - ex: docker.img got hosed and would just like whatever selected reinstalled with current templates one after the other Myk I'll look at it, but initially I'd say that this is a non-starter. Although its possible for CA to send the appropriate commands to the docker service, I don't think it would be wise to bypass dockerMan. And AFAIK there is not a way for me to bypass the prompting within dockerMan and have it install a container directly. But, I'll investigate as I do see the usefulness of this (at least with checkboxes - having it do everything will not happen regardless)

Yes, I know it's a lot of work, but the current format + CA own elements is a hell to support, to begin with. Plus, they don't survive the Docker Manager edit, so user templates lack a lot of info. A possible future step is to include something like CA into unRAID itself, so we need to make the changes right now to make it future proof. And if you don't want to change your templates you don't have to, the Docker Manager will remain backward-compatible with them, so no muss no fuss there. In a collective of developers like LS, some tasks can always be delegated, if I'm not mistaken. I can see where integrating the categorizer into dockerMan would have advantages, since every maintainer (plugin or container) has to ultimately use it. I don't believe that you'd integrate the additional tags required for plugin operation, but that's not a big deal. Those maintainers can still use the categorizer. But, in the case of containers I would personally integrate all of the commonly used unofficial tags (ie: project). <Changes> you'd probably have a complaint about, since its not markdown, but rather full HTML with syntax changes - (see the link for it). Changing that formatting would cause nothing but grief since it is VERY commonly used by all the maintainers. Moving Beta into Categories isn't a big deal, and CA would be able to deal with it as necessary. The MinVer and MaxVer were created mainly for plugins, and in the absence of those tags (of which no one uses them with the exception of my own plugins), CA automatically applies MinVer of 6.0 for containers (6.1 for plugins) and MaxVer of the user's unRaid version. (Additionally, CA's moderation system has the ability to override ANY tag that a maintainer might choose) Since the categorizer is public domain, you can pretty much do anything you want, and legitimizing my unofficial tags is always a plus. The only caveat that I see however is that since CA is not integrated into unRaid, officializing the <Category> tag does tie my hands should the need (however remote) for an additional entry into that.

Squid, it's time to add things in Docker Manager. My two cents is that we could ditch <Beta>(add that to <Categories> element), move <Date> to <Version>(YYYY.MM.DD format like it's done in plugins) and adopt <Changes> as a history log. Not sure about <License> or <Project> tho. Please I need enlightenment me about <MinVer> and <MaxVer>. How are they important? I also don't quite understand why you're proposing this anyways? All of those entries (especially categories and beta) are internal use in CA anyways, and I don't particularily see them being used within dockerMan itself.

Squid, it's time to add things in Docker Manager. My two cents is that we could ditch <Beta>(add that to <Categories> element), move <Date> to <Version>(YYYY.MM.DD format like it's done in plugins) and adopt <Changes> as a history log. Not sure about <License> or <Project> tho. Please I need enlightenment me about <MinVer> and <MaxVer>. How are they important? MinVer and MaxVer were both added in conjunction with plugin integration into CA, but they are also usable on containers. Basically all they are is set the minimum unRaid version and maximum unraid version that a particular app (container or plugin) are capable of running on. Execution is denied by default otherwise. More important to plugins than to containers. <Date> accepts any valid date that can be parsed via strtotime() and does not have a set enforced format. However, with all containers and authors currently using it, an outright move wouldn't be recommended, rather support of both. (and even there, but I believe that there is also no set format for <Version> in plugins, but its rather a strict greater than or less than comparison done (ie: I think that I could have <Version>1</Version> and the plugin manager would handle it perfectly. <Beta> I don't think of a particularily a category per se, hence why it's separated

My post stands. Quoted the response about MC and offered up other alternatives to avoid dropping into a command line. The response about MC came after the suggestion to install UD, and my suggestions all require UD to be installed

no - you just need to set the host path for /config to be something like /mnt/cache/appdata/plex. (First create a cache-only share called appdata)

I removed the option to move the apps tab down to settings because as a general rule it is a very bad idea to be modifying system files (which is what I was doing). This was always going to be a temporary fix. Starting with 6.1.7, you can go into display settings, and move the User's tab to settings which will fix those display aberrations

Set network type to host (which removes all options to map the ports) Then you should be able to access the UI through port 32400, if the permissions issues aren't also messing it up. You have to jump through major hoops to get plex to run in bridge mode

The two have nothing to do with each other. Plex basically won't run unless in host mode (which then requires 32400) The permissions issue, IDK. I run linuxserver's Plex which as one advantage automatically checks and assigns the correct permissions everytime it starts up

Plex needs to run in host mode unless you map a ton of other ports (buried in threads at plex.tv) Net result is that you're going to be stuck using 32400 (which isn't an issue unless your other plex server is also running on your server)

or either Krusader or Dolphin docker applications (or even do it through Windows and the network) Dockers would be fine but why use Windows and the network for a share mounted with unassigned devices directly on the unRAID server? I agree, but the question was and that is an option

or either Krusader or Dolphin docker applications (or even do it through Windows and the network)

Can't replicate on either server doing a reboot followed by a fresh install. But, odds on its only going to be a minute or two. What's going on here is that CA tries and download an "appfeed". If for whatever reason that fails, then it reverts to a legacy mode where it has to download each template individually Downloads of the appfeed are a second or two. Downloads of the templates if the appfeed fails could be a minute or two. (Could take longer if another process (NZBGet?) is completely saturating your download bandwidth) Due to how unRaid's emhttp works (single threaded), the webUI is indeed locked up while this is happening. (and all parts of unRaid suffer from the same "flaw" - only one thing can happen at a time) If it doesn't recover, your easiest solution is to hard reset the server. If you don't want to do that, then your solution is to have to kill the task. Run htop and kill the task that has a path of something like /usr/local/emhttp/plugins/community.applications/include/exec.php Either way, you may want to investigate your DNS settings in the network settings (try 8.8.8.8 and 8.8.4.4). Some people have also had issues with running their server through a VPN service where the VPN is outright blocking the sites that CA has to hit.

appFeed is back up and running (thanks KodeStar), but the update above will prevent CA from crashing again should this circumstance ever happen again! Now I can get back to my mourning :'(

My Pet Rock Died - Fixed: In the case of improperly formed appfeed*, CA will now automatically downgrade to legacy mode without having to manually hit Update Applications. - Major overhaul of the javascript

NM The appFeed is currently suffering an issue (the feed is actually only half there, but it downloads correctly so CA is not going down to legacy mode). Hitting Update Applications will allow you to use CA until the feed is fixed