trurl

root@unSERVER:~# which diagnostics /usr/local/sbin/diagnostics root@unSERVER:~# So diagnostics command is definitely there unless you somehow did something to the OS files.

Looks like it successfully rebuilt disk2 despite all the pending sectors on new disk3. I assume disk3 was the other drive you replaced. You should return it and get a good drive. All drives mounted and showing plenty of contents.

What version of Unraid do you have. This should definitely work unless your version is many years old or there is something wrong with your installation. Do you have a current flash backup?

But did you actually do memtest?

If it was never formatted, you will not have written any files or folders to it in the normal sense.

This looks like you put the numeral 1 fdisk -1instead of the letter l fdisk -lBetter to copy/paste instead of trying to type it yourself

Attach Diagnostics ZIP to your NEXT post in this thread.

I should note, however, that I have not tried this myself. It is even possible it won't allow you to do it even though it should work. I wonder if @JorgeB has tested that scenario.

In the case where you have dual parity and are upgrading a parity disk, only the size of the parity disk not being rebuilt matters, since the rebuilding parity disk is invalid until rebuilt. The valid parity disk can rebuild a single data disk as long as it is not larger than the valid parity disk. The invalid 2nd parity disk can be built as long as there is no more than one invalid disk in the array. You can rebuild both parity if no data disks are invalid. You can rebuild one parity and one data disk if the other parity and all other data disks are valid. You can rebuild 2 data disks if both parity and all other data disks are valid. No data disk can be larger than any valid parity disk. So, you still could have rebuilt both at the same time.

What do you get from command line with this? fdisk -l /dev/sdc

/var is a path in the host OS. Unraid OS is in RAM, so anything mapped there will not survive reboot. You must map to actual storage, typically a user share in /mnt/user/...

I was able to open your incomplete download with 7zip. Not clear why it didn't know your drive assignments. Did you replace the flash drive for some reason? Or did you New Config without retaining the assignments? All of your configuration, including drive assignments, are in the config folder on flash. A new install on flash will not have your disk assignments.

You attached an incomplete download of the diagnostics. The complete diagnostics would be a ZIP file. The reason I wanted to look at them is because I suspect you will have the problem again due to something about your hardware.

Attach Diagnostics to your NEXT post in this thread

Data from deleted files are still on a disk until their space is reused, they just aren't part of the filesystem anymore. You could see if UFS Explorer can recover anything from that disk besides the files it currently has.

There can be some advantages with managing different types of files differently. For example, movie files will typically be larger than music files, so a share for movies would have a larger Minimum Free setting than a share for music. TV files will often have multiple episodes and seasons, so it might be good to have related tv files on the same disk, which is determined by Split Level. Do you know anything about the files you might be missing?

UDMA_CRC_Error_Count are problems communicating with the disk, not problems with the disk. Possibly the disk you replaced had nothing wrong with it. A common reason for problems when replacing a disk is disturbing the connections of other disks. Looks like that has happened with disk1. You can't reliably rebuild any disk unless all other disks can be reliably read. Can't tell anything about your user shares, maybe because of these other problems. Shutdown, check connections on all disks, SATA and power, both ends, including splitters. Reboot and post new diagnostics.

Other than appdata and system which is all on cache as they should be, you only have a single user share, which means you can't configure Unraid to manage different types of data differently. Simpler that way but less flexible. Default allocation method is Highwater. It is a good compromise between using all drives eventually, without constantly switching between drives simply because one drive temporarily has more free than others. One of the features of Unraid is it allows individual drives that are not currently being used to spin down. But they can't spin down if it has to constantly switch drives for writing (and maybe even for reading since files that are stored at the same time are often read at the same time). Nothing in diagnostics that gives a clue about any possible missing data. Syslog only goes back to last boot, and normal file I/O isn't logged anyway. Do you allow access to your server from outside your LAN?

This would be unusual, unless all disks were the same size and all user shares were set to "most free", which is the least efficient allocation method. Are you sure it was missing, or did you just think it should have the same as the other disks? Not enough information to know what might have happened. Attach Diagnostics ZIP to your NEXT post in this thread.

The problem disks are on different controllers, but none of the other disks on either controller is having problems. Do you have a backplane or are there separate cables going to each drive?

I do see this though May 10 11:27:28 Tower kernel: mdcmd (9): import 7 sdn 64 5860522532 0 WDC_WD60EFPX-68C5ZN0_WD-WX42D8445KLT May 10 11:27:28 Tower kernel: md: import disk7: lock_bdev error: -2 May 10 11:27:28 Tower kernel: md: import_slot: 7 empty May 10 11:27:28 Tower kernel: mdcmd (10): import 8 sdd 64 3907018532 0 WDC_WD40EFAX-68JH4N1_WD-WX22DB05D97H May 10 11:27:28 Tower kernel: md: import disk8: lock_bdev error: -2 May 10 11:27:28 Tower kernel: md: import_slot: 8 emptyNot sure what that's about. A few search results from a few years ago. I'll take a closer look.

I forgot to mention Mover, so it was busy moving things to the array while those disks were emulated. Shouldn't be a problem, that's what emulation is for. But it does mean the physical disks are more out-of-sync with the array than before. Maybe I overlooked it, but I didn't see in syslog where you actually reassigned the disks. I never use the work "add" when I mean "replace". "Add" means to a new slot in the array, not to the same slot that you are replacing. Did you try to "replace", or did you try to "add"?

Probably not the reason for your problem, but SSDs in the array cannot be trimmed. Better if those are put in pools outside the array. It is not required to have an array with Unraid V7.

UDMA_CRC_Error_Count is a connection problem not a disk problem. The disk that was Parity disconnected and reconnected as an Unassigned Device. You would have to do the SMART extended self-test on the Unassigned Device. But SMART for that disk looks OK, it has recently passed an extended test, and syslog seems to indicate a connection problem instead of a disk problem. Just check your connections and rebuild parity to the same disk. https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself After you get it reassigned as parity and rebuilding, you can click the SMART warning (👎) for that disk on the DASHBOARD page and Acknowledge, then it won't warn again unless it increases.