Squid

IIRC dynamix smart drive db update was released when there was an issue with the smartdb then currently present in unRaid being way out of date. Since then, LT has been updating the smartDB with every release, so the plugin shouldn't be needed anymore (hence why its not available in CA which is why FCP yells about it).

Odds on, you do not have the EXACT same mapping for your downloads (both host and container) mapped to the radarr container. (Or you're downloading into the appdata share for NZBget instead of a dedicated download share) The actual error from Radarr will tell the story

It should work just pointing the config folder to the already existing appdata folder. Ask in the lsio support thread for plex to confirm Sent from my LG-D852 using Tapatalk

So I discovered also today. Waiting for a response from @jonp with regards to this They did work when I posted originally. Sent from my LG-D852 using Tapatalk

To always stay up to date with Plex (although personally, I don't see why you need to -> but I'm not a heavy Plex user), you should switch to the linuxserver docker app

Because the same thing happens on my system, and its probably not very likely that this app is going to be maintained / fixed, it is going to be removed from the Apps tab...

oops. Go to Main, Cache Devices, Click on Cache, and you can manually edit the comment out...

Couldn't think of any funny pic to post Enhanced: Update plugins now refreshes page instead of reloading * far more convenient Enhanced: Install plugins now refreshes page instead of reloading * far more convenient Enhanced: Increase search speed on installed apps Added: Paging when utilizing favourite repositories Code cleanup

Better as public. You want to make them as accessible as possible I had a typo that was preventing the disk shares / comments from being properly restored. Updating the plugin corrects the typo, and will also remove the existing comments (if you had done multiple test trips). However, a reboot may be required after installing the update for unRaid to pickup the comment changes...

Docker Tab, advanced then delete the orphaned image. Then either the apps tab, previous apps section or Docker, Add Container and select the my-Plex template will bring back the template. Edit it and reinstall...

Its not so much your mappings on your templates, but rather where you are telling the download clients where to put the incomplete downloads. If you don't specify to put them onto a folder you've mapped, then they wind up being stored within the docker.img file. Either that, or you're a victim of excessive logging... http://lime-technology.com/oldforum/index.php?topic=40937.msg405070#msg405070 http://lime-technology.com/oldforum/index.php?topic=40937.msg475225#msg475225

http://lime-technology.com/oldforum/index.php?topic=40937.msg481150#msg481150

Odds on either sab or deluge (or possibly sync) is winding up downloading into the docker image (and things like that don't really show up under the virtual size) Check your path mappings on the template for those apps AND the settings within the apps for where they are downloading to. And expanding is simple. Settings - docker - disable docker. Advanced view. Increase the size and reenable docker. Apply Off the top of my head, when properly configured your installed apps would utilize maybe 10Gig.

While the file is being transferred, its named ...partial~ Once the transfer is completed, the partial file should be deleted. Does the partial file show up if you browse the folder via the shares tab (click on the folder icon)

Personally, I wouldn't worry so much about the wear and tear on the flash drive. They aren't that fragile, and transfers of registrations are super easy. But, I'm not going to support putting the tail onto any other device as the boot drive is the only persistent storage device that is guaranteed to always be available. Rather than try to link files, you can just tail it yourself with something like tail -f /var/log/syslog > /whereEverMountPoint/syslog.txt You won't however get the extra debugging information that may or may not shed any clues on the issue.

Can't remember 100% the issue I found on the forums that prompted the thing about /mnt, but if you've got no problems, then just ignore it. The CPU throttle thing I would hazard a guess that its because your system is running as a VM. No idea if your CPU is actually throttling down or not. You can tell with this command: cat /proc/cpuinfo | grep MHz

Give me the diagnostics for when this happens. There's 2 other lines that are logged in the syslog that aren't logged in the RP log's

It's tailored to unRaid, and takes the approach of waiting for an attack to happen against certain files and when that happens stops all smb write access regardless of how inconvenient that may be to you. IE: It's your absolutely last line of defense, and should never be your first and/or only... https://github.com/Squidly271/ransomware.bait/

Good catch. Fixed

Without seeing the diagnostics before a reboot showing a backup (or the backup settings as a last resort), I don't know.... Myself and others use this successfully all the time, so my best guess is misconfiguration...

Command line in unRaid or the CA confine file editor plugin.

slacker

You're not a digital hoarder?

Under bait files, there's no problem With bait shares, there's 2 issues with excluded files #1 - The memory requirements to implement a watch on every file is immense. IIRC during my testing, inotifywait did not sent an event if a linked file was deleted (ie: encrypted / re-written, and the source removed) Because of that an attack cannot be detected unless every single file is watched or the directory is simply watched for any changes. #2 - The response time for inotifywait decreases with every additional file being watched. (As an aside, I just tried it and simply creating a .ds_store file will trigger an attack because of the change in the folder) I have no clue under what circumstances Finder creates those files, but I believe I have seen in the forums here instructions on how to stop finder from creating them in the first place. I really don't know what to say beyond stop your script from deleting them from bait shares, or stop finder from creating them in the first place. But no matter what, always keep in mind that this plugin is the last emergency line of defense (for the files on the server only), and to always make the necessary precautions on all your other networked devices to prevent any ransomware attack from happening in the first place. The attack won't originate from the server, but from another networked device, and its highly probable that all the files on that particular device will be trashed no matter what.

In a nutshell, you tell it that whenever say disk 8 spins up to also spin up disk 10. IMHO Its only useful for a share that spans multiple disks where any delay in accessing a file from one disk and then accessing a file from another disk is completely unacceptable due to the need to spin up the other disk. IE: Music shares.