Squid

Nope under all circumstances it should finish within 90 seconds worst case if you uninstall and reinstall you wont lose anything Sent via telekinesis

NOTE: As of unRaid 6.8.0-rc1, these functions are now included in the base OS (the plugin update checks and the banner warning system) Not really an API, but with the release of CA versions 2019.03.27+, I'm making available to any plugin a function to toss up a banner if the plugin is out of date This is not a replacement for the built-in plugin update notification system, but an extension of it. The banner only appears when the user is on the .page file for a plugin, and the check runs in the background so as to not interfere / slowdown any other scripts you may be running (Side effect is that this banner is less disturbing on CA's own page when an update becomes available than it's previous banner used for this purpose) All a plugin dev has to do is add in the following code to their page file to utilize this at the basic level. $(function() { if ( typeof caPluginUpdateCheck === "function" ) { caPluginUpdateCheck("fix.common.problems.plg"); } }); However, since not all plugins have their own page and are rather inserted as tabs into an existing page, then the option exists to specify a div to place the upgrade notice instead to only have it appear on their own tab (ie: the main page for UD) $(function() { if ( typeof caPluginUpdateCheck === "function" ) { caPluginUpdateCheck("ca.mover.tuning.plg",{element:".pluginUpdate"}); } }); ... <div class='pluginUpdate'></div> The complete usage is as follows: caPluginUpdateCheck("fileNameOfPlg",{options},callback(result)); Options are as follows name: string /* name of the plugin - if not present, defaults to fileNameOfPlg - Recommended to use*/ element: DOM element/class /* if present, the banner shows up in whatever div you specify */ noDismiss: true | false /* if true, then the dismiss "x" will not appear - defaults to false */ dontShow: true | false /* if true, then the banner will not appear under any circumstance - defaults to false, only useful when using callbacks */ debug: true | false /* forces the banner to always show - defaults to false */ The callback function if present is passed a JSON string of { updateAvailable: true | false, version: "version of update", min: "minimum OS version that the update requires", changes: "the changelog from the update", installedVersion: "currently installed version" } The callback function allows you to do whatever you want with the information provided - I use the callback on many of my plugins to have the currently installed version displayed somewhere on the page if some one has problems and posts a screenshot caPluginUpdateCheck("community.applications.plg",{noDismiss:true,name:"Community Applications"},function(data) { if (data) { var result = JSON.parse(data); $("#caInstalledVersion").html(result.installedVersion); } }); Notes: The code snips will NOT cause any problems if CA is not installed, or if it hasn't been updated (ie: the test for if the function exists) If the plugin's minimum OS version specified is greater than the currently installed OS version, then the updateAvailable will always be false, and the banner will not appear (You can test for this if updateAvailable == false and version > installedVersion) This function is not dependent upon plugin update checks being enabled in unRaid, nor a check for updates ever having been performed by the user. The results are always live, and are only performed when hitting the page file for the plugin in question. Dismissing of updates is handled via a cookie that expires when the user's browser session closes. But, if the banner is dismissed and another update becomes available then the banner will reappear.

Today's update brings a laundry list of improvements (see the changelog), but as far as the end user is concerned: Able to click on the icon to bring up the pop up in addition to the info icon. Vast majority of applications now have graphs on the info pop up showing how it's trending from month to month, number of downloads per month, and total downloads. The meta data for the graphs is collected for each app gradually over the course of a month, and the graphs will ultimately populate to show a full year's data. Most apps currently have 2 months worth of data, but the appfeed has now begun to populate the 3rd month. (Side note: I'm surprised and pleased that @sparklyballs as of this writing has one of his containers (acestream) show up in the trending list - Currently ranked #9 🍺) Another "under the hood" addition is opening up a function for other plugin authors to utilize to notify users if there's an update available for their plugin (an enhancement to the current plugin notification system) - This will be documented in the Programming Thread.

Yeah, Looks Good. Thanks..

The next rev of unRaid will include on the context menu for docker applications a "more info" (you can also get there via the next rev of CA also) which will take you to the dockerHub page for any particular container which usually has more set up information than what is in the OP on the support thread. I too also sincerely applaud the efforts of the guys / girls / indeterminate over at LinuxServer.io Without them the docker landscape across the board (not just unRaid) wouldn't be where it is today, and many of their innovations / ideas have taken hold and have now been implemented not just by tinkerers but also by major corporations. @dockerPolice is just a knob for criticizing

"airsonic" isnt a valid repository You've modified the template and changed that entry to an invalid one Sent via telekinesis

I dont know. Taking your advice and having a life, aka having to work

Enable mover logging in settings schedule and itll log what its logging and you'll see in the syslog Sent via telekinesis

For next time, that link included directions on how to get the docker run command

Post your docker run command https://forums.unraid.net/topic/57181-real-docker-faq/#comment-564345

👍

None of these are possible with dockerHub searches. Nothing I can really do on dockerHub searches, but assume certain things that are generally correct. One of those is assuming the latest tag You didn't need to do that. All you had to do was search for elasticsearch, download the first result (which is the official version), and in the repository section append something like :5.6.9 for the tag. The full list of available tags you can use is available on the dockerHub page (which you can get via the support icon when doing the search) This is all why dockerHub searches are an advanced feature as you can't install a "wild" container without reading the dockerHub page for the container to find out what options, paths, ports, and tags you can use.

Yeah, because when I did that I never would have thought that 6.6.7 was ever going to be a thing as 6.7 had already started its testing. Fixed.

Nah. Won't populate the share list. @dlandon is going to have to make some adjustments

If I do manually mount with the complete command, then everything does work mount -t cifs //WINDOWS10/GitHub /tmp/GitHub -o username=nunya,password=business,dir_mode=0777,file_mode=0777

Yup. No go...

Everything is password protected

I'm also getting this, and unfortunately this is a major issue for my server. Tried to downgrade the plugin, but it appears that the older .txz's no longer exist on GitHub (and the one other (2019-03-13 also doesn't want to work) ( Mar 26 19:21:04 ServerA unassigned.devices: Removing configuration '//WINDOWS10/GitHub'. Mar 26 19:21:24 ServerA unassigned.devices: Mount SMB share '//WINDOWS10/GitHub' using SMB1 protocol. Mar 26 19:21:24 ServerA unassigned.devices: Mount SMB/NFS command: mount -t cifs -o '//WINDOWS10/GitHub' '/mnt/disks/WINDOWS10_GitHub' Mar 26 19:21:25 ServerA unassigned.devices: Mount of '//WINDOWS10/GitHub' failed. Error message: mount: /mnt/disks/WINDOWS10_GitHub: can't find in /etc/fstab.

A dangling image isn't the same as an orphan you can remove those by just clicking on the icon Sent via telekinesis

Yeah, I don't see any fundamental reason for those errors, so just Settings - Docker - Stop the Service Delete the image file Restart The Service Apps - Previous Apps - Check off your apps, and hit Install Multi

Are you sure those are the right diagnostics? They're from August 2018

Your cache drive is fully allocated Device size: 111.79GiB Device allocated: 111.79GiB Device unallocated: 56.00KiB (as an aside, I'm not a fan of btrfs for cache drives if you don't have a cache pool) To fix: https://forums.unraid.net/topic/62230-out-of-space-errors-on-cache-drive/?tab=comments#comment-610551

Because of this Mar 23 17:20:29 DeathStar kernel: BTRFS info (device loop3): read error corrected: ino 0 off 699817984 (dev /dev/loop3 sector 1383216) Mar 23 17:20:29 DeathStar kernel: BTRFS info (device loop3): read error corrected: ino 0 off 699822080 (dev /dev/loop3 sector 1383224) Mar 23 17:20:30 DeathStar kernel: BTRFS warning (device loop3): loop3 checksum verify failed on 712540160 wanted 3182DA00 found 19A992C1 level 0 There is a problem with the docker.img file (or its with the cache drive - impossible to tell from the syslog snippet) But, whether or not the server restarts for you or not, the shutdown was clean based on the snippet, so you can just hit the reset button. Because of the segfaults, I would run memtest for at least a single pass from the boot menu (ideally more though). When you actually restart unRaid, post your full diagnostics.

To fix the support link on the dashboard / docker tabs, first go to the Apps Tab (to insure the lists are all up to date), then go to plugins, Install Plugin and paste the following URL into the field https://raw.githubusercontent.com/Squidly271/misc-stuff/master/fix_template.plg However, due to caching of some values by unRaid, the entry on those tabs won't actually change until you either stop and restart the docker service or reboot your server.

Exactly. As I've mentioned when in HOST or as an unique IP you cannot change the port numbers the app will use.