itimpi

The process of changing RAID levels is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.

Did you make sure the array was stopped, and the replacement disk was not mounted in Unassigned Devices before trying to assign it to the array?

You might want to give the path of a file that you think is going to the ‘wrong’ disk disk so we can compare it to your share settings to see if it is likely to have a problem. You have several,shares set to a Split level of 2 and for those shares once the top level folders have been created (corresponding to the share name and the first sub-folder) on a drive any further contained content will be constrained to the disk where those 2 levels were created regardless of the other share settings as Split Level always takes precedence in case of contention when choosing a drive for a file. There is a good write-up on how Split Level works here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.

If you mean can you simply proceed with the good drives then that will be possible. However I am a bit concerned when you say you are worried about the data on the parity drive as a parity drive does not contain data - just parity information. Am I missing something and you think there is some data to be recovered?

It is always a write error that disables a disk, although a read error can trigger a write error if as a result parity is used to reconstruct what should be on a sector and Unraid then tries to write that back to correct the read error, and that write then fails.

In principle that is correct. However when you start the array with the drive unassigned Unraid should be emulating the missing drive and you should check that it contains the expected content before proceeding with the rebuild steps. The rebuild will only end up with what is on the emulated drive so you do not want to overwrite the physical disk with that if the emulated contents do not look correct.

Yes. If it is not mounted that explains the other symptoms. Make sure it is FAT32 format and is labelled UNRAID (all caps). If possible use a USB2 port and/or flash drive. USB3.x should in principle work just as well but does seem to sometimes cause problems.

A possibility is to plug that drive into a Windows system and use a data recovery utility like UFS Explorer to see what it thinks is on the drive. UFS Explorer is not free if you actually want to use its recovery capabilities, but you do not have to pay for th option to simply scan the drive looks for files.

That suggests that the device /dev/sde may have dropped offline.

The first point applies when you have more disks failing than you have parity drives. Unlike more traditional RAID systems under Unraid any disk that has not failed will still have its data intact and accessible even when you have more drive failures than parity drives. On a traditional RAID system everything is lost in such a scenario.

Personally I think that would be too dangerous as users would tend to blindly click it and then not make sure that parity is correct meaning any future recovery could result in corruption at best. Going via the New Config tool does at least mean that a few more steps are required so a little more caution is likely from users.

since you were coming from an old Unraid version then maybe the drive is in ReiserFS format so you would need to use reiserfsck rather than xfs_repair. In either case do not forget to include the partition number as omitting that will cause the superblock not to be fund.

If you can get in at the console then try the ‘df’ command to check that the Unraid flash is successfully mounting at /boot. you might find this section of the online documentation to be of use?

These things are always much easier when you already know the answer There are continual improvements being made to the online documentation so always worth checking there. Often the Help built into the GUI helps as well.

Yes as with 1 parity drive you can recover from a single disk failing. in fact if you start the array with disk1 removed it will act as if it were still present and UnRaid will say that it is emulating it (using parity) although you are now not protected against the parity disk failing as well. When you plug in the replacement for disk1, then Unraid will rebuild its contents from the ‘emulated’ drive and you will be back in a protected state. The procedure for replacing a failed disk is covered here in the 0nline documentation accessible via the Manual link at the bottom of the Unraid GUI

you definitely want the docker.img file on the cache (or a pool) for performance reasons. That is normally stored in the ‘system’ share which you say is already on the cache so nothing to do if that is the case

Your 'system' share (which contains the docker.ing file) is on disk1 which so running any container will tend to keep it (and parity) spun up. You can follow the steps outlined here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI to get it moved to the cache.

You are likely to get better informed feedback if you attach your systems diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post.

My guess is that the cache disk is either not online or has a corrupt file system that needs fixing. The diagnostics should tell us either way.

No. All checks that come to a controlled ending should end with entries in the history file. The only time I can think of where this might not be true if if an unclean shutdown happened in the middle of the check. It might be worth pointing out that if you have the Parity Check Tuning plugin installed then the history entries will contain additional information over those generated as standard by Unraid even if you are not using the plugin to run the check in increments.

You should also ensure that you have the Minimum Free Space setting for the cache/pool to be larger than the biggest file you expect to transfer. That way if the free space drops below this value then Unraid will start automatically by-passing the cache for any new files so that transfers are slower but you do not get an error generated.

As far as I know the Parity Swap procedure works exactly the same as when using parity1.

There should never be 2 copies of the same file in Unraid so are you sure that is what is happening? I would expect the file to stay on the cache drive and not get moved to the array due to how Linux handles mv. As was said using /mnt/user0 should work.

The .key file needs to be put into the config folder on the flash drive it is licensed for.

Yes - there is a setting for the cache drive. if running 6.8.3 then it is under Settings - Global Share Settings If running 6.9.2 then click on the pool name to set it for that pool.