trurl

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

How did you get transmission installed as a plugin? All transmission plugins are deprecated and that type of application should definitely be a docker. There are literally hundreds of docker applications available for Unraid, including transmission. Remove that transmission plugin. The very first plugin you should install is Community Applications, and use it to install dockers and any other plugins. https://forums.unraid.net/topic/38582-plug-in-community-applications/

SMART for disabled disk looks OK. Didn't check others, do you have any SMART warnings on the Dashboard? Syslog only has a few minutes after reboot so nothing about what might have happened. You should setup Syslog Server in Settings so syslog can be saved instead of lost on reboot. Do you know how to re-enable the disk? Not related, but why is your system share on the array instead of on cache? You want that on cache so your dockers / VMs will perform better and so they won't keep array disks spinning.

Dec 6 07:54:55 Tower emhttpd: unclean shutdown detected ... Dec 6 07:55:05 Tower kernel: mdcmd (40): check nocorrect Dec 6 07:55:05 Tower kernel: md: recovery thread: check P ... ... Dec 6 09:23:33 Tower kernel: md: recovery thread: P incorrect, sector=1586007976 Dec 6 09:23:33 Tower kernel: md: recovery thread: P incorrect, sector=1586008008 Dec 6 09:23:39 Tower kernel: md: recovery thread: P incorrect, sector=1587187688 Dec 6 09:23:39 Tower kernel: md: recovery thread: P incorrect, sector=1587187696 Dec 6 09:23:39 Tower kernel: md: recovery thread: P incorrect, sector=1587187704 Dec 6 09:23:42 Tower kernel: md: recovery thread: P incorrect, sector=1587880552 Dec 6 09:23:43 Tower kernel: md: recovery thread: P incorrect, sector=1588069608 Dec 6 09:23:43 Tower kernel: md: recovery thread: P incorrect, sector=1588069624 Dec 6 09:23:52 Tower kernel: md: recovery thread: P incorrect, sector=1589865904 Dec 6 09:23:52 Tower kernel: md: recovery thread: P incorrect, sector=1589865912 Dec 6 09:23:52 Tower kernel: md: recovery thread: P incorrect, sector=1589865920 Dec 6 09:23:52 Tower kernel: md: recovery thread: P incorrect, sector=1589865928 Dec 6 09:23:52 Tower kernel: md: recovery thread: P incorrect, sector=1589866056 Dec 6 09:23:53 Tower kernel: md: recovery thread: P incorrect, sector=1589997040 Dec 6 09:23:53 Tower kernel: md: recovery thread: P incorrect, sector=1589997088 Dec 6 09:23:53 Tower kernel: md: recovery thread: P incorrect, sector=1589997104 Dec 6 09:23:53 Tower kernel: md: recovery thread: P incorrect, sector=1589997296 Dec 6 09:23:54 Tower kernel: md: recovery thread: P incorrect, sector=1590007120 Dec 6 09:23:56 Tower kernel: md: recovery thread: P incorrect, sector=1590090488 Dec 6 09:23:57 Tower kernel: md: recovery thread: P incorrect, sector=1590134664 Dec 6 09:23:58 Tower kernel: md: recovery thread: P incorrect, sector=1590165472 Dec 6 09:24:12 Tower kernel: md: recovery thread: P incorrect, sector=1593228992 Dec 6 09:24:18 Tower kernel: md: recovery thread: P incorrect, sector=1594907032 Dec 6 09:24:27 Tower kernel: md: recovery thread: P incorrect, sector=1597095944 Dec 6 09:26:37 Tower kernel: md: recovery thread: P incorrect, sector=1636990432 Dec 6 09:26:52 Tower kernel: md: recovery thread: P incorrect, sector=1640489872 Dec 6 09:27:21 Tower kernel: md: recovery thread: P incorrect, sector=1647481728 Dec 6 09:28:18 Tower kernel: md: recovery thread: P incorrect, sector=1662632216 Have you been doing all your testing with a parity check underway? And obviously your parity needs correcting. Why did you have an unclean shutdown? You must not power down or reboot with the array started. Only shutdown or reboot from the webUI so Unraid can stop the array cleanly.

Go to Tools - Diagnostics and attach the complete Diagnostics zip file to your NEXT post. It contains SMART for all disk, syslog, and many other things that give a more complete understanding of your situation.

What happens if you set security to Public?

Get a diagnostic before freeze. Also Settings - Syslog Server to mirror syslog to flash. Go ahead and disable docker service for now until you can get the system to stay up just to simplify things for troubleshooting.

What is the SMB Security setting for the User Share?

Not nearly enough information. Is this over the network? From inside a VM or Docker?

When doing filesystem repair you should capture exactly your input and the resulting output so you can post them.

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/