Squid

Most likely because for some reason you (inadvertently) deleted /config/plugins/dockerMan/templates-user/nameOfTemplate.xml. Alternatively, there was an issue with 6.5.1? where if you renamed an application, then the template wound up getting deleted wrongly

But what is the path mappings from your download client Sent via Tapatalk because my wife thinks I spend too much time on the computer

Yeah, now that I'm not looking at this on a phone, you are correct there

Additionally, once you fix this it might not take effect until new downloads happen. Old ones may still reference the incorrect mappings. Sent via Tapatalk because I'm either at work or enjoying the summer

Your passing through /Media on one app and /media on the other. Linux is case sensitive, so those are two different paths Sent via Tapatalk because I'm either at work or enjoying the summer

That's what cache dirs does. It's a Continuous loop of find of all the directories you include in its settings. There ar circumstances where it can keep drives spun up, mainly if you have it included your Plex appdata for example, because the millions of files in appdata will quickly flush the cached inodes for all the other folders, and find will have to spin up the drives to get the info. Generally the only included folders would be stuff like movies or TV or music Sent via Tapatalk because I'm either at work or enjoying the summer

You should post the entire error message and the mappings for both deluge and sonarr Sent via Tapatalk because I'm either at work or enjoying the summer

It's from dynamic cache dirs. It gets stopped when the array stops Sent via Tapatalk because I'm either at work or enjoying the summer

If you're accessing your server via https then you can't insert an iframe referencing http. Security violation enforced by the browser and nothing I can do about it.

Not that I've ever done this, but can't you just copy the contents of the download to a newly formatted (FAT32) flashdrive named UNRAID, and then execute make_bootable_linux which is on the flash drive?

Doubtful You should post your diagnostics

2 things: It's a .png you've saved onto the flash drive, not a .jpg. Convert it to be a .jpg called background.jpg The cp command should be before the line that has emhttp in it.

I can guarantee the txz online definitely is not corrupted (I reinstalled numerous times earlier today) What I would do is delete on the flash drive /config/plugins/community.applications, reboot and then try it again.

Fixed next release of unRaid

If you're stuck living in your parent's basement, then you definitely needed something to pick you up

Nope. I actually submitted a PR a long time ago to make backups of the .plg files when dynamix updates a plugin which would allow for rollbacks, but it was denied (and pointed out) that since many plugins by design do not allow the mechanism to work that it shouldn't be approved as it would imply something that the system can do that it actually can't. And realistically, this is correct, as it's up to the plugin author (and docker author by extension) to support rollbacks and there's no conformity there. My personal belief however is that plugins should always be held up to a high standard, and if a release proves faulty then it should immediately be rectified. This even extends to many, many applications available under Windows as an example. Not every app supports reinstallation of previous versions, and only the latest version is listed available for download.

Which it is. But, find me a different OS where you can effectively format a hard drive (delete the docker.img file), select a couple checkmarks and every single application is reinstalled and up and running with no re-configuring required at all in a matter of minutes. But, I do realize that at least in the past, one of the complaints of docker as a whole (not limited to unRaid) was its disk space utilization. Either way, the problem lies squarely with docker itself, and not the unRaid installation of it, and the majority of users have zero problems with the docker.img file. The minority who do, because its such an easy process to redo everything I always suggest the nuke option. At the end of the day, it takes far far less time than to figure out what went wrong on docker's end.

Probably because the docker.img doesn't duplicate layers of the various apps until they are modified by the app. (EG: all of LSIO / binhex's apps all utilize the same base image, and have a huge overlap of layers. When the first app is installed, it has to grab all of the layers and store them. The 2nd and subsequent apps see this, and it doesn't redownload or take up the space in the image. If the 2nd app makes a change however in one of those layers, then the entire layer gets copied to the 2nd app, and the change is made (aka : COW - Copy On Write) This is all handled at the filesystem / docker level, and the du command probably isn't smart enough to figure it out, since it goes through folder by folder and simply adds up the filesizes in that folder (ie: my /var/lib/docker/btrfs is 49G, but my image size is 20G -> I have zero problems) df /var/lib/docker Will return the correct usage on the docker image. Supposedly though, docker has had problems with removing dangling images (images / layers that don't belong to anything anymore). You can get rid of them via docker rmi $(docker images --quiet --filter "dangling=true") But I've never had the command return anything but an error which means that no dangling images were found Beyond that, if you really want to clean up the docker.img file, the easiest fastest way without causing any heartaches or pulpitations is to simply stop the service, delete the image, re-enable the service, then on the Apps tab (Previous Apps) check off all of the apps you want installed and hit Install Multi. 10 Minutes later, it'll be like nothing happened.

Not that hard. Downloading 2 files and replacing a date string There's many different ways for a plugin author to handle installation / updates, not all of which are compatible with a roll-back. If the plugins were auto-updated via CA Auto Update, then you can easily roll back (if the plugin supports it) via removing the plugin, and then reinstalling the plugin and instead of pasting a URL browse to /boot/config/plugins-old-versions/NameOfPlug/DateOfRollbackRequired/nameOfPlug.plg Your mileage may vary. This would most likely have worked with Preclear. It will definitely work for any and all CA / CA related plugins. Dynamix branded plugins it will not work at all, and cannot be rolled back. Other plugins, I don't know one way or the other. The main determination on if this works or not is how the author chose to name the installation package referenced within the .plg

The URL looks identical, but it's not. There's some weird unicode character in there before the the "s" in https: This is the 2nd report of someone pasting a weird URL that on the surface looks correct. How did you copy the original URL? Where is your rough geographical location? Try this instead https://raw.githubusercontent.com/Squidly271/community.applications/master/plugins/community.applications.plg EDIT: The next release of unRaid now has code in it to remove control characters, etc from the url when installing a plugin.

Barring any other separately installed packages of which I don't know (I don't use Preclear), you can download these files https://github.com/gfjardim/unRAID-plugins/raw/master/archive/preclear.disk-2018.05.03.txz and https://github.com/gfjardim/unRAID-plugins/raw/master/archive/preclear.disk-2018.05.03.md5 Save them on the flash drive at /config/plugins/preclear.disk, then edit the file /config/plugins/preclear.disk.plg and change the date that's probably listed at the top of the file to be 2018.05.03 and reboot. But, since I don't use the plugin, this is untested, but it'll either install or it won't.

Your best bet here is to toss Fix Common Problems into troubleshooting mode. And then doing what it says following the crash. Additionally, take a picture of whatever is on the local monitor at the time of the crash and include it with the post, along with your complete hardware specs.

You mean something like this: Copy the file to your flash drive (named something like background.jpg) Add the following to you go file (config folder on the flash drive) before the emhttp line cp /boot/background.jpg /usr/share/slim/themes/default/background.jpg

The preclear plugin has not been updated AFAIK to remove those errors. Possibly it's fixed on the 2018.07.09 update though. You can also silence the errors by Tips & Tweaks plugin and disable Show PHP errors (you've enabled that). That option is really only for developers anyways and is only used to find those errors listed above. (Which are simply warnings at the moment, and do not affect anything at all)

Nope. /boot isn't an unassigned device, so you can just leave it at RW. Not that RW:Slave causes any problems though.