itimpi

This will not be the issue as preclear is never mandatory. The advantage would have been showing up the reallocated sectors before you added it to the unRaid array at the expense of the additional time to run the preclear.

The libvirt.img file gets created as soon as the VM service is enabled regardless of whether you have any VMs.

In the syslog you posted I can see that there is a message for each drive of the form: Not something I can remember seeing before but I guess it may well be relevant.

Have you tried clicking on individual disks on the Main tab to see what file system unRaid thinks they are set to? Maybe it has lost track somehow of the fact that you have encrypted disks?

No idea - you should ask in the support thread for the plugin. Did creating the required folder before trying the mount sort out doing it in the 'go' file?

Just checked and you are right! I suspect an auto-correct kicked and got missed. I used to have edit capabilities to fix this sort of issue but that seems to have been lost with the recent upgrade of the wiki I’ll have to contact Limetech to see if they will trust me enough to allow me to do so in the future

That is quite normal - rerun with the -L option.

Linux is case sensitive - the command is xfs_repair.

I would not have thought that the folder you are trying to mount to exists at that point so you would have to create it first. Is there any reason you do not let the Unassigned Devices plugin handle this for you (setting the disk to automount in the UD settings for the disk)?

Have you made sure that you do not have a console (or screen) session open with the current directory being one on the array as this will stop the array completing the unmounting correctly and thus can lead to a subsequent unclean shutdown.

CRC errors are connection issues and nearly always related to the cabling rather than the drive.

It should - but you need to do it to confirm.

A regularity scheduled parity test (e.g. monthly) is a good alternative to a SMART test. It has the advantage that you can use the Parity Check Tuning plugin so that it runs in increments outside prime time to minimise the impact on your daily use of the unRaid server.

worth pointing out that for many of the timeouts you have to enabled Advanced view.

The only way to do this will be to use Tools -> New Config. I would suggest that you start by using the option to retail current configuration and then return to the main tab to make the required changes. If you think parity is valid then you can tick the "parity is Valid" option to avoid an immediate parity rebuild, but if you do so I would recommend doing a parity check afterwards to make sure. The existing data drives will be left with their data unchanged, but keep the old drives intact until you are back up and running to keep a recovery option available.

Yes - that is required to be able to boot in UEFI mode.

Do you have single or dual parity? I am guessing single parity? UnRaid can never recover more drives than you have parity drives and with single parity if both a data drive and the parity drive missing the standard recovery will not work. Why did you remove these drives in the first place? If you give more background we are more likely to be able to help. It the drive are still physically connected to the unRaid server then posting your systems diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post will at least allow us to see the SMART information for the drives.

Just copy the pro .key file into the ‘config’ folder on the flash drive. As long as it is the one that corresponds to the flash drive that is all that is required.

You cannot add a parity disk and another data drive at the same time. You should be OK if you do this in 2csteps.

Do you have the USB stick set up to support UEFI boot (I.e. no trailing ‘~’ on the EFI folder)? I have seen the symptoms you describe on some newer systems unless you boot in UEFI mode.

What happens when you try? you should provide your system’s diagnostics zip file (obtained via Tools -> Diagnostics) taken after attempting to add a disk attached to your next post if you want any sort of informed feedback

You cannot do what you want as simply as you would like do you have Single or Dual parity? With single parity there is a way to achieve what you want while maintaining parity protection as the slot number is not part of the calculations for parity1. With dual parity it is not as easy as for parity2 the disk slot number is part of the parity calculation. regardless - I assume you have backups of this important data as parity is no substitute for a backup.

Have you turned on mover logging to confirm what files are trying to be be moved? looking at the diagnostics I would expect the system to be trying to move appdata files from disk2 to the cache as there is space on it and that share is set to “use Cache = Prefer”.

The sdX identifiers are not relevant to unRaid as it identifies disks by serial number (and the sdX designation is allocated dynamically and can change between boots). The only time it matters is if the disk drops offline after boot and then comes back with a different sdX designation as that scenario is not handled by unRaid.

Chances are that the way you are selecting to move the files is creating the folders before moving their contents. The Split Level settings you have then force the content to the drive where the folders have been created.