itimpi

Yes. The flash drive is in a standard FAT32 file system so easy to copy all the files off onto a location on the PC.

Memtest is an option on the Unraid boot menu. The version supplied with Unraid only works if you are not boot img in UEFI mode and are not using EEC memory. If you want a version that works with UEFI boot mode and/or EEC memory you can download it from memtest86.com (for Licencing reasons that version is not included with Unraid).

It should not be as that will be within the temperature range that the drives are rated for. However it could mean that thermal expansion is adversely affecting the SATA connections as it as notoriously fragile type of connector as far as good connection goes.

If there is no Lost+Found folder then it is very unlikely that anything was lost. You can only be certain, however, if you have checksums for the data that should be on the drive. Almost impossible to say. Any sort of glitch that can cause a write to the drive to be lost could cause this.

Since the drives were disabled it is the EMULATED drive that got repaired - not the physical drive. All the rebuild process does is make the physical drive being rebuilt match the emulated ones

That looks good - just restart the array in normal mode and the disk should now mount OK with all your data intact.

Handling of unmountable disks is covered here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

You need to rerun without -n but adding -L.

You are likely to get better informed feedback if you post your system’s diagnostics zip file.

The last message on the screenshot suggests it is probably a problem reading the flash drive. You may find this section of the online documentations accessible via the ‘Manual’ link at the bottom of the GUI to be of use.

Another thing that you get for ‘free’ with the plugin installed is enhanced Parity Check history as it adds extra items such as the type of check, the number of increments and the total duration. This can be useful if at a later date you want to look back at the history of parity checks. You get this even if you are using the built-in parity check functionality (when it is working as expected) and have disabled the plugins pause/resume functionality.

Fair enough, but with the correct settings it will replicate the built-in 6.10.3 functionality.

An alternative is to use the Parity Check Tuning plugin that DOES work with the 6.10.3 release (as well as earlier releases) and gives you even more control over the process than the built-in functionality.

Yes. The share level setting is designed to handle the case of array drives getting full, not a pool/cache getting full. In the past there was a time when the higher of the share level setting and the pool setting was (incorrectly I believe) applied to the pool/cache but I think this is no longer the case.

This is what I would recommend. No reason not to be running the extended test on both drives in parallel as the test is completely internal to the drive. The process for rebuilding the drives is covered here inthe online documentations accessible via the ‘Manual’ link at the bottom of the GUI but it would be a good idea to wait until you have gotten feedback on the diagnostics after the extended tests before going ahead with that.

I agree -but there is no reason that help text cannot mention overflow to the array with correct share settings (if just for consistency).

This is a frequent recommendation for getting back to a default configuration. If you feel a bit paranoid (no reason not to be when protecting your data) you always have the option of renaming the original file rather than deleting it.

I guess that help text could do with an update to make this clear. I think it is mentioned on the Share Settings page but not here. Personally I would like the default for pools/cache to not be 0 so new users are less likely to get bitten by this issue, but that is a different conversation.

Most of the time the upgrades are painless but is always worth taking precautions against anything going wrong. Make sure you have a backup of your flash drive before attempting the upgrade as you can then easily revert by copying the backup back onto the flash drive. It is a good idea to turn of auto-start of the array until you have done an initial check after the upgrade. Temporarily disabling the Docker and VM services is also not a bad idea. The one item that most frequent lay causes problems is if you have VMs with hardware pass-through as the IDs of the hardware can change. In the worst case you can find an ID associated with a GPU now ends up assigned to a HBA. Make sure that you do not have my VMs set to auto-start until you can check the passed through hardware.

All recent versions of Unraid REQUIRE you to have a password for the GUI, and it should be set via the GUI to ensure it is persistent. If you have a password set and you are not being prompted for it then that means the browser must be caching it.

You should have a Minimum Free Space value set for the cache (click on it on the Main tab to get to this setting) to stop it getting completely full. Ideally this value should be something like twice the size of the largest file you expect to write (or larger). When the free space on the cache drops below this value then for subsequent files Unraid will by-pass the cache and start writing directly to the array. If you do not set a Minimum Free Space setting then Unraid will keep selecting the cache for files and If they will not fit you will get out-of-space type errors occurring.

It depends what you want for the final destination? Using Yes means you want the files to eventually end up on the array. using Prefer means you want them to end up on the cache. You can click on the text in the GUI for this setting to get more detail.

If this is via splitters then it can definitely cause issues as you can end up under load trying to draw more current than can stably be delivered over a single cable. If you are using splitters the molex->SATA seem to be less problematic.

FYI: Only the zip was required as all the other files you posted are already in the zip.

No - what you have just done erases all its contents beyond any chance of revovery. What was recommended was to instead try and mount it as an Unassigned Device as that might have mounted OK and you could then have copied files off it instead of trying to sort out the Lost+Found folder on the emulated disk.