trurl

That syslog has timestamps from February 17 (don't know what year). Is your server clock correct? Also, that syslog doesn't show anything about when the trouble began. Do you have earlier ones in the /var/log folder, such as syslog.1, syslog.2?

There is a Help (?) button on the menu bar. It will turn on/off Help for all pages in the webUI. You can also toggle help for a specific setting by simply clicking on its label. Here is a link to a post in the FAQ that explains the nuances of the Use cache setting in much more detail: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#comment-537383 That FAQ is pinned near the top of this same subforum. Lots of other useful info in that FAQ and also in the Docker FAQ pinned near the top of the Docker Engine subforum.

Yes is definitely wrong, since Yes means move from cache to array. Prefer is OK or Only. Prefer is the only setting that can help you get it moved to cache. Prefer means move from array to cache, but you can't move open files so more would need to be done to make that work. Specifically, while docker service and VM service is enabled you can't move docker and libvirt images. Simplest is probably to just disable and delete those images, set system to cache-only, and recreate them so they will go on cache.

I haven't used this version in a very long time, and I didn't really do much (if any) support back then. My guess is it is disk3 that is actually disabled, and disk2 is only missing. So it is really insisting that you put the original disk2 back so you can rebuild disk3. That is my guess, maybe someone else will have another idea. Maybe we will know more after you get us the information I mentioned. Don't do anything without further advice.

There is no way to obtain the diagnostics mentioned in other threads for this very old version of Unraid. I have moved your post to the Legacy Support subforum. See this post pinned near the top of this same subforum for instructions on how to get us the syslog and SMART for all disks: https://forums.unraid.net/topic/9277-how-to-report-a-defect-and-capture-syslog-and-smart-reports/

Parity1 dropped so I think it is only checking parity2 now.

I think it was just a mistake. It sounds like you should be good to go. The main problem happens when people enable docker and VM services before they even install a cache drive. Then those are installed to the array and, though not difficult, a number of steps are required to get them moved to cache where they belong since open files can't be moved.

Not related but I noticed some FCP warnings in your syslog. You shouldn't ignore these unless you know exactly why they don't apply to your specific use (and these do apply): Dec 5 21:10:01 Tower root: Fix Common Problems Version 2019.11.22 Dec 5 21:10:01 Tower root: Fix Common Problems: Warning: Share Disk2 test is set for both included (disk2) and excluded (disk1,disk3,disk4) disks Dec 5 21:10:01 Tower root: Fix Common Problems: Warning: Share Films is set for both included (disk2) and excluded (disk1) disks .... Dec 5 21:10:06 Tower root: Fix Common Problems: Warning: Dynamix SSD Trim Plugin Not installed Dec 5 21:10:06 Tower root: Fix Common Problems: Warning: Syslog mirrored to flash You shouldn't set both include and exclude and there is never any good reason to do so. Include means ONLY and Exclude means EXCEPT, so using one or the other not both, covers all possibilities. Remove one or the other. In fact, your setting for Films isn't even consistent. And I don't know why you would even have a share named Disk2. It doesn't appear in your user shares, and include / exclude settings don't make any sense for a disk share. Maybe you removed that share after it was logged. Hope you can clarify this one for me. And you don't want to mirror syslog to flash permanently since you will wear out your flash drive. That should only be done temporarily as a troubleshooting measure. Better yet set syslog server to write to one of your user shares. Also, your system share has files on the array instead of all on cache where they belong, so your dockers won't perform as well due to parity and they will keep array disks spinning.

You can always go directly to the correct support thread for any of your dockers by simply clicking on its icon on the Dashboard or Dockers page and selecting Support.

Go to Tools-diagnostics and attach the complete Diagnostics zip file to your NEXT post

Nothing obvious in those. Post docker run command as explained in the very first link in the Docker FAQ.

I just use a cache- only share for my recordings.

Go to Tools - Diagnostics and attach the complete Diagnostics zip file to your NEXT post.

I don't use that application, but some have experienced a similar issue using other applications. I have had it happen to me using rsync to my backup server, for example, and there are other reports of it happening with Krusader. What happens in the case of rsync and Krusader, the disk is still below highwater mark, and rsync, for example, has a lot of folders and files to write. It starts by creating all of the folders in advance, and then begins filling them with files. The folders were written to a disk with plenty of room, and the files got written to those folders, with the result that they all tried to go to the same disk. In my case with rsync I saw what was happening and I also noticed that it was proceeding in alphabetical order. So I just started at the other end of the alphabet and started moving the empty, pre-created folders to other disks so when it came time to fill them that is where the files went.

Interesting. And of course you have a typo in this text that you didn't repeat in your mapping: /mnt/user/cache would be a user share named cache, not the actual cache disk. There have been reports of user shares giving problems with databases on other dockers. See here: https://forums.unraid.net/bug-reports/stable-releases/sqlite-db-corruption-testers-needed-r598/