Squid

You need to run a balance on your cache pool - It's completely allocated Data Metadata System Id Path RAID1 RAID1 RAID1 Unallocated -- --------- --------- -------- --------- ----------- 1 /dev/sdd1 929.46GiB 2.02GiB 32.00MiB 1.05MiB 2 /dev/sdc1 929.46GiB 2.02GiB 32.00MiB 1.05MiB

Were you running the Memtest from Unraid's boot menu? If so, it will not find any ECC issues (and most servers with ECC will completely halt the system if it runs into an uncorrectable ECC error). Setup a new boot stick and download from https://www.memtest86.com/ These problems won't affect the "stability" of the server. However based on your screenshots your flash is dropping offline and reconnecting. Try a different port. If it continues, then replace the flash drive and transfer your registration

If there's nothing in the logs for the container (and assuming there's no issues with the server itself), then you'd have to start really looking at the differences between the 2 instances and research on the project itself (probably on GitHub issues)

Any thoughts @bonienl?

It's not related to the backup. It's happening daily at ~11pm What else goes on at that time? (I'd guess something with tdarr node?)

You don't need to ever use remote paths within sonarr. The path mappings between sonarr / radarr etc just need to match 100% the path mappings on your download client See https://forums.unraid.net/topic/57181-docker-faq/?tab=comments#comment-566086

Just an error from the controller basically stating "Huh! The drive was here and now it isn't"

chmod 0777 -R /mnt/user/appdata/whoogle-search

Doubtful you have an actual 3600MHz kit (or 2666 for that matter) Rather you're running an overclock on the memory (XMP or DOCP profiles). If problems persist, disable that overclock

Pretty sure that you had in the past on that flash drive run SimpleFeatures and installed the lighttpd plugin. Delete or rename from being a .cfg file

Actually, the change log shows that it's already been fixed. Is the plugin up to date?

Same thing also applies to only a single cache pool. If you move between shares and the source file is sitting on the cache drive and the destination's share has use cache: no, the file will stay on the cache drive and never be moved to the array by mover.

The only user which can log into the GUI is "root" Windows has a rather stupid feature where it "remembers" credentials to network shares which ultimately results in half the time things don't connect if you've changed around the permissions / passwords (on all platforms). Clear out the credentials in credential manager in control panel and try it again.

By using Krusader, you are effectively bypassing the "system", resulting in this behaviour The way that every OS in existence operates on a move is that first the file / folder is attempted to be renamed to the new location. Only if it fails does the copy / delete process (physical move) take place. Because Krusader is working from the single mount point (/mnt/), the rename will always succeed, resulting in files being location in apparent violation of the rules. Options to avoid this is once 6.10-rc3 is released to install a File Manager plugin at the same time, or 2 do file operations via Windows and move between the shares, or map the shares to Krusader individually and move between those mounts

More likely a flash problem. Transfer it to a new flash

Not quite sure. Try this rm -rf /tmp/community.applications rm /boot/config/plugins/community.applications/community.applications.cfg And reload the apps tab

yes

Does the blue boot menu appear? Re run the make_bootable script (as administrator), check the boot order.

Try this: Delete this folder from the appdata and restart the program (It'll redownload the codecs) \Library\Application Support\Plex Media Server\Codecs Plex is a rather "unique" program across all platforms where one of their very constant updates will break something that already worked, or it corrupts itself.

On installations from CA there should also be a popup showing if there is a port clash on the host side If in doubt, the docker run command for the app which won't start will tell you exactly why (if you see an execution error when trying to start it)

No. The message from FCP says invalid folder "cache" within /mnt In your screenshot it shows "cache". You do not have a pool named "cache", so something is creating it. Look first at any docker apps (hit show more settings) for something that has a path mapping directly referencing /mnt/cache Fix that and reboot and then see what FCP says again

Via issuing a PR to this file: https://github.com/limetech/webgui/blob/master/plugins/dynamix.vm.manager/include/libvirt_helpers.php

The latest release is 6.10-rc2 which was released on November 1. RC3 is just around the corner with a stable to shortly follow Unraid does received regular security updates as the versions are released, but only in the case of very severe issues would a patch release be issued for a previously released version.

All you basically have to do is download the zip file and then overwrite all of the bz* files on the flash drive with what's in the archive. Reboot