itimpi

This is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

Do you have Tirbo Write enabled? If so writing to any disk would cause all drives to spin up and in the diagnostics something is writing to disk6.

Have you tried disabling the docker and VM services to see if the disks then spin down?

@jedimstr You might want to consider installing the Parity Check Tuning plugin to give you more control over the parity checks. Since you mentioned being reluctant to shutdown then the fact it allows checks to be restarted from the position previously reached might be relevant?

Not sure what is going wrong - looks like it could be a cabling and/or power issue. Since the drive started throwing errors so quickly I would lead towards it being a power issue. You mention having 4 x 18TB drives. At the moment there are only 2 plugged in and neither has had a SMART test run on them although you implied you had done so. The extended SMART test tends to be the best check on the health of a drive.

Where does it actually get to? Are you trying to boot legacy or UEFI? It is possible that this might help if the problem is reading from the flash drive.

That looks good. A correcting check reports as 'errors' each sector it corrects. The next check should report 0 errors.

You should contact support to get this resolved.

you may find out that the description of New Config in the online documentation useful. As you will see from reading it you do not need to lose any data. You will only lose data if you accidentally assign a drive containing data to the parity slot so do you know which is your parity drive(s). If not then this can help identify parity drive(s).

No reason there should be any data loss. Do you know what your disks assignments should have been?

Sorting out the lost+found folder is unfortunately a manual task. You have to decide if it is worth the effort. The Linux 'file' command can at least help by giving the content type of each file.

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

Do not think you can do both at the same time, so replace the parity drive first.

That is not an attribute I have seen mentioned before. None of my drives report it. No idea if it is significant or not.

Well the Sandisk Ultra Fit is being detected at the hardware level and I do not see how that can happen unless there really is one. Are you sure you do not have one plugged in internally to the server?

What is the device you are trying to get rid of? The diagnostics show you have a Sandisk Cruzer Force and a Sandisk Ultra Fit plugged into the system.

You really need to upgrade this to 4GB if you want to use it with the current v6 (which is now the recommended minimum). It will probably run most basic functionality with 2GB but certain features (such as OS upgrade via GUI) may well fail to work correctly.

Most of the time a drive is disabled (has a red ‘x’ against it) the drive has not really failed catastrophically, just had a write to it failed. In such a case data can often be retrieved from the physical drive rather than the emulated one.

There were some examples given earlier in this thread where it was ‘convenient’ to have entries in a template of the type that could trigger an error at run time. I agree fixing the templates is a tidier solution, but as there appear to be lots of frequently used containers whose default templates could trigger this error then the old behaviour was made available as a stop-gap to cut down on the number of people (incorrectly) reporting docker as broken after updating Unraid. There is nothing stopping you from NOT installing the plugin and fixing the templates for any containers you use that then fail.

The files/folders there will have cryptic names, and the Linux ‘file’ command can help with identifying the content type of files. Other than that it is a manual process to inspect them to sort out their original names. if you have decent backups frequently easier to restore missing files from there.

It is hiding errors in the docker templates. If you have templates with the errors containers would stop starting correctly after the Unraid update. These errors used to be ignored so it is re-instating that behaviour.

There is no concept of ‘transferring data back’ as the rebuild works at the raw sector level. That is why we normally recommend doing the repair on the emulated drive before doing the rebuild as that keeps the physical drive intact to give other recovery options. Do you have a lost+found folder on the drive? That is where the repair process puts any file/folder for which it cannot find the firectory entry to give it the correct name. Not really much point as the rebuild has made the physical drive agree with parity so it achieves nothing other than confirming that parity agrees with the data drives (although if you now got errors it would indicate some other hardware underlying issue) Do you have backups of everything important or hard to replace? Parity is not a substitute for such backups as drive failure is not the only way to loose data.

Difficult to say. Could be any copy method that was not done over the network.

You follow the steps I gave earlier. Make sure that the parity drive and disk1 correspond to the serial numbers I gave for them.

Will that stop it showing up for Licencing purposes?