Squid

Your cache drive is full /dev/sdb1 120G 120G 20K 100% /mnt/cache Free up some space and everything will probably work again. Can't remember if 6.2.4 supports this, but you can also set your share settings for the appdata share to be use Cache: prefer which will allow your appdata share to overflow onto the array in emergencies. Either way, it would also be prudent to update to 6.3.5 anyways

Are your applications using any SMB mounts made by Unassigned Devices? If so, this is the probable answer https://forums.lime-technology.com/topic/57181-real-docker-faq/?page=2&tab=comments#comment-608304

You should post your diagnostics

It means that you've never had any containers set to autostart via unRaid. You shouldn't see that though - minor issue. Will update Correct

Not quite following what you mean by this, but you want to set up the path mappings like this: https://forums.lime-technology.com/topic/57181-real-docker-faq/?page=2#comment-566086

Can you see you're shares / programs / whatnot by referencing their IP address directly? I never had name lookup work properly when connected to the VPN, and figured that its just one of those things and did things the way that I know that it works.

I assumed you already moved the file(s) to the appropriate folder within the TV show / Movies share Just mark the download as failed, rescan the disk for the show and everything will be all copacetic.

Rescan the drives for episodes should fix it.

Probably your problem is that The /data host path doesn't match exactly with your download client

You really should rename batteries included. The * is an invalid character when dealing with SMB. Whether you use it now or possibly later it is something you're only going to have problems with

Additionally, your cache is currently at 85% full. You might want to consider setting your shares (except for appdata and downloads shares) to bypass the cache drive altogether. You won't see a huge decrease in access time for media files, but you will give yourself some more breathing room which again will make the system more responsive altogether as appdata and downloads will tend to stay on the cache drive instead of falling back to the array.

I think this is what is happening. You've got mover running every hour. Because of the logging done by mover, it has very rapidly filled up /var/log. Under settings, Scheduler, mover settings, disable mover logging. If nothing else, it makes for a nicer syslog to read. Mover keeps attempting to move appdata from the array to the cache drive. All well and good, but it is continually unable to do so completely because you've got docker running. Settings, docker, stop running. Then Main, Array Operation, run mover. After its done, re-enable docker. Now everything should be on the cache drive and mover won't complain as much, and as a bonus you'll see a big speed bump. Of course, you're going to have to reboot first to accomplish this as with /var/log filled, strange things result.

You can work out the command for tar itself to do it. Google tar man page

docker Hub searches still show the Add button, but only to really differentiate where you exactly are in the program. You should always if at all possible install the "regular" apps

Gotta ask: What setting? Your screen shot showed you could install no problems

How you've got it set up now is correct. BUT, IIRC SabNZBd is a tad strange in that if you change things when stuff is already queued, the queued items still go into the original places, which account for the problems you're having. Clear out the queue, have Sonarr / Radarr send over a new download and then see what happens

Yes

A while back we went with a more language agnostic UI. Click the Hard Drive Icon to install (hit help to see everything you can do)

This is the problem Label: none uuid: 5d187e56-3a61-43d8-bb94-7e846712a666 Total devices 1 FS bytes used 121.36GiB devid 1 size 232.89GiB used 232.89GiB path /dev/sdh1 Wait for @johnnie.black (the btrfs god) Although btrfs is stable, anecdotally there is less problems with using XFS if you have no intention of ever getting a cache pool going.

the entire zip

Cache drive btrfs? Wouldn't be a bad idea to post the diagnostics if it is

Edit the container, switch to advanced mode and get rid of the extra parameters entry (you've only got a dual core cpu to work with and the template is pinning the app to 4 cores of a 32 core system)

Due to the pervasiveness of Community Applications (https://forums.lime-technology.com/topic/38582-plug-in-community-applications/), very few authors still post all of the required information required to install docker apps (and even plugins) to get the job done without CA installed. Install it, and don't look back

If you access your server via https then its a browser enforced security violation to display an iframe as http Switch it to https if it supports it, if not then you're SOL I'll have to add a note to the plugin for this.

Also, while not directly related to your problem, you do have this: 184 End-to-End_Error 0x0032 097 097 099 Old_age Always FAILING_NOW 3 on ST4000VN000-1H4168_Z300T4WM-20171213-1626 - This is a failure of the electronics (cache) on the drive itself If you don't already have it, enable notifications in Settings. Drives with attributes in Failing State should never be ignored.