itimpi

Something that seems to work for some people is to use Rufus to format the flash drive to FAT32 and then simply extract the contents of the zip version of the release onto the drive. You do not mention if you are trying to boot in legacy or UEFI mode. If UEFI mode make sure the EFI folder does not have a trailing '-' in the name. You also do not mention if when you go into the BIOS it is seen as a bootable device,

I am confused - sdb in your screenshot is not a What do you want to boot from there? Unraid always boots from a flash drive, and that flash drive needs to be present all the time Unraid is running. Unraid does not have an 'installer'. Device sda is the current Unraid boot device. Do not understand this statement at all? Your fdisk shows that sdb is partitioned with a Linux file system whereas sda (the boot drive) has a FAT32 file system.

Check in the config/shares folder on the flash drive that the .cfg files corresponding to your shares have the same capitalization as the folders on the drives corresponding to the share. A mismatch can cause this sort of problem. If necessary correct this; check the share settings; and then try running mover again.

One test you could try to confirm this if you do not have another PSU to try is to remove (for the time being) one of the data drives and see if you can then complete the parity check. I have found if a PSU is borderline to exceeding its capacity then you can get unpredictable crashes. Note that if you do this you will need to later use the New Config tool to get the removed drive back into the array with its data intact.

I wonder if that is enough. Do you have any way to test with a higher capacity PSU. The fact that adding the 4th drive makes it start crashing does suggest it could be power related.

No. Mover ignores any share that does not have secondary storage set. You need Primary storage=cache; secondary storage=array; and mover direction=cache->array to get mover to move files from cache to array.

Yes. When doing a manual upgrade you are overwriting all the bz* type files that already exist in the root of the flash drive.

Have you tried wiping any existing file system on the drive in case there is one already there that is confusing things.

Most people have app data in the 'appdata' share configured to stay on a pool and then have a folder within that for each container (which is the default configuration for docker). You do not seem to have gone with that approach. Not necessarily wrong, but just different.

Not directly related to your question but I notice in the diagnostics that you seem to have a lot of shares stating that they are on the 'dockers' pool but not configured to be there! Have you by any chance created lots of top level folders there (which then show up as user shares) rather than perhaps having an 'appdata' share there with a sub-folder for each container.

All of the GUI source is freely available on GitHub although Limetech have to approve any changes before they are accepted into an Unraid release.

You Do have a running system - just one with no storage 😊

I would think it is the file system corruption on disk7 that is stopping the User Shares showing up correctly.

I would suggest doing a manual upgrade rather than doing it via the GUI with such a small flash drive.

Do the shares (folders) show up if you look directly at the drives from the Main page rather than going via the Shares page? It could be worth running a check filesystem on you drives as file system level corruption has been known to cause this type of issue. In particular the diagnostics suggest that disk7 has file system level corruption that needs fixing.

No. You just rebuild the parity onto a new parity drive while you are protected by the second parity drive.. Having done that you can then upgrade the other parity drive. Finally replace the data drive. Not much point in doing parity checks in between the steps unless you think your hardware has issues so that the parity/data rebuilds are likely to have errors.

The fact that a disk was encrypted is irrelevant if you are clearing it - the process is identical for both encrypted and unencrypted dtives as you are writing zeroes to every sector on the dtive.

I would recommend using the Dynamix File Manager bult into Unraid 7 for this sort of issue as it bypasses the docker mapping level so is more likely to be accurate.

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread. It is always a good idea to do this to allow us to see the current state of your system and so we can see logs.

Has SSH access been enabled under Settings->Management Access?

I think this was a potential issue with the 7.2-beta1 release.

If you must split a SATA power connection on a PSU cable then do not split it more than 2 way. That normally works OK.

you can add new extensions to be treated as text files by editing the config/editor.cfg file on the flash drive.

No. You might want to read the description of this tool in the online documentation

Yes you could do this. You could then use the any file copying program you like to move (or better use copy) the data across to the other drive - if you do not have a preference then the Dynamix File Manager built into Unraid 7 might be the easiest. Note that while doing this your data is unprotected as you have no parity. Once all the data is on the 12TB drive you can use the New Config tool to put the 14TB drive as parity and the 12TB drive as disk1. When you start the array after doing this parity will be built to get your array back to a protected state.