trurl

Almost impossible to lose everything since each disk is an independent filesystem. Currently, only the 3 disks in question are at risk, and chances of recovery seem very good.

We don't know that the physical disks 6 and 19 have unmountable filesystems, because those physical disks have not been read since they became disabled. Instead, those disabled disks are emulated by reading all other disks and getting the data for the disabled disks from the parity calculation. So, the failing disk14 is providing some of the bits for the emulation of the disabled disks. It is the emulated disks that are unmountable.

Not entirely sure I understand what you are saying in this post. You must rebuild a disabled disk, whether the disabled disk is parity or data. There is no need to clear a disk you are going to rebuild, because the rebuild will completely overwrite the disk anyway. Are you saying that you had to clear the disk again before it would let you rebuild? That is the part I am not sure I understand. The correct procedure to rebuild to the same disk, whether parity or data Stop array Unassign disabled disk Start array with disabled disk unassigned Stop array Reassign disabled disk Start array to begin rebuild

So you have an external HDD connected by USB as parity, and all your array disks are SSDs? Seems like a number of bad ideas combined into one design.

Could be failing disk14 is actually the cause of the unmountable filesystem on the emulated disks. Maybe the best way forward would be to New Config / Trust Parity and then try to replace / rebuild disk14 and if there really is corruption on the other disks try to repair after that. The main thing that troubles me with making that recommendation though is that I don't know why those other disks became disabled. The syslog in those first diagnostics you posted may have a clue since they probably cover those events, but it was quite a lot of stuff that I haven't seen before. I am going to ask @johnnie.black for a second opinion.

have you done memtest?

What exactly is the "it" in this statement?

Unraid installs itself into RAM fresh from the archives on Flash at each boot. Think of it as firmware except easier to work with.

Are the other 2 disks still testing?

Make sure you don't mix disks and user shares when moving / copying or you can lose data.

What about these? ls -lah /mnt/cache/libvirt ls -lah /mnt/disk3/libvirt

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.