trurl

Check connections on cache. Maybe change SATA cable. Which controller is this using? What do you get from command line with this? ls -lah /mnt/disk3/system

Unlikely to be related to your problems, but your system share has files on the parity array. Also, looks like you may be having connection issues with cache: Aug 26 12:02:47 Laybourne kernel: ata10.00: failed command: WRITE FPDMA QUEUED Aug 26 12:02:47 Laybourne kernel: ata10.00: cmd 61/40:58:10:ed:27/01:00:0d:00:00/40 tag 11 ncq dma 163840 out Aug 26 12:02:47 Laybourne kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Aug 26 12:02:47 Laybourne kernel: ata10.00: status: { DRDY } Aug 26 12:02:47 Laybourne kernel: ata10: hard resetting link Maybe these are what is filling your log

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post. Also see here for how to save your syslog somewhere you can get it after crash:

Copied this to Feature Requests here: Changed Status to Closed Changed Priority to Other

Took me a moment to understand what you mean by the 3 buttons, since I normally used Tabbed mode. I have copied this "bug report" to Feature Requests for you since that is where it belongs.

No harm in trying it though. If there is a problem you can just

I think some have reported problems with the script. You can New Config/rebuild parity without the disk. That other method is probably slower anyway.

web pages typically don't receive right clicks since the browser uses that for itself.

The SMART tests are on the physical disks and the filesystem checks/repairs are on the emulated disks. But if you are also running SMART test on disk14 then that disk is being read for the emulation. Let the SMART tests complete.

Do you have backups? You must always keep another copy of anything important and irreplaceable.

Lets see what the check (-nv) shows.

From the command line, what do you get with these? ls -lah /mnt/cache/system/libvirt ls -lah /mnt/disk1/system/libvirt

Please attach plain text files, not Word documents. We shouldn't have to install software in order to help you,

This is always a good idea and in the current situation, having the original may be another solution to the filesystem corruption of the emulated disks if the repair doesn't work.

There are some other things about how you have dockers configured that we can discuss later after your array is stable. Looks like emulated disks 6 and 19 are unmountable. Even though these disks are disabled, they are emulated by reading all other disks and getting their data from the parity calculation. Unfortunately, the result of these emulations are corrupt filesystems. And, the emulated data is what will be rebuilt when you do rebuild the disks. So, the first thing will be to try to repair these filesystems. Study this wiki and come back with any questions: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui Be sure to capture the output so you can post it.

Maybe obvious but did you specify a port number?

Ask on the UD support thread

Be sure to capture the output so you can post it.

https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

From the command line, what do you get with these? ls -lah /mnt/cache/system ls -lah /mnt/disk1/system

CA Backup can do that to an Unassigned Device or to a remote share mounted with UD.

You didn't give the unique portion of the disk serial numbers. Often the last 4 characters are all that is needed. I can see from diagnostics which are the disabled disks though. Unraid won't disable more disks than you have parity, so only 2 disks are actually disabled, disks 6 and 19. Disk6, there are 2 disks that match that serial number you gave. Last 4 characters of disk6 are SAT0 Disk19, there is only one TOSHIBA so that isn't a problem. Last 4 characters of disk19 are FS9A SMART for both of those disabled disks looks OK to me. As for the ST3000 disk, you have 3 disks that match those parts of the serial number you gave. Of those, disk14, last 4 characters 0PV5, has 32 reallocated, not necessarily a reason to replace. Which disk were you referring to for ST3000? You might run an extended SMART test on each of those disks. Lots of stuff in syslog I don't know much about, including some things that appear related to encryption. The array wasn't started in those diagnostics, so can't tell if any disks are unmountable, and many other things that might be useful. Can you start the array and post new diagnostics?

Not sure how long a particular rating would be useful. New "parts" are always coming out to replace the old parts, and the old parts, if you can still get them, are often more expensive than the new ones since the old are no longer made and have limited supply.

You posted while I was typing. Are you confident your backup has the correct disk assignments?

Do you have any record of your disk assignments? A recent screenshot, diagnostic, or syslog is all it would take. And even if you don't have any record of your disk assignments, as long as you don't accidentally assign a data disk to a parity slot then you should be able to boot up in Unraid without affecting your data. Just don't assign parity if you don't know which disk is parity, simple as that.