itimpi

That indicates there is actually no specific partition on the drive (as that would be sda1).

Files in the appdata share have permissions that are specific to each container, and there is no guarantee that these will be compatible with viewing or editing them over SMB.

it looks like disk have slightly different ways of reporting their serial numbers under 6.10.0 on your system. You should be able to: Use Tools->New Config and use the option to keep all assignments return to the Main tab and correct all drives to have their new version of the serial numbers tick the “Parity is Already Valid” checkbox start the array and with any luck everything will now come up as normal.

As far as I know Unraid only tries to read the SMART data if it thinks the drive is active (spun-up). Sounds as if the USB enclosures are not tending to correctly report the drive status when they have spun down the drive.

Interesting! I only get 1 partition showing with the blkid command on my Unraid system so somehow a difference has crept in. Be interested to see what any others experiencing this issue show as the output of the blkid on their systems or if the apparent difference is a red herring. I would guess we must be getting around the time that Limetech folk come online (being US based) so maybe they will have something useful to say

No idea, but it is something different to what I normally expect to see. Limetech may have an idea when they see the screenshot. It could be worth trying to see of you can get the drive formatted with a single partition to see if it then boots? if it does turn out to be related to having 2 partitions in some way it might explain why only some people are encountering this issue.

That screenshot shows there are two partitions on the drive sda1 and sda2. Normally there would be only one partition (sda1) and that would be the one labelled UNRAID. Not quite sure what caused you to end up with 2 partitions, but it could well be what is causing the booting problem.

What makes you ask that? If there is a EFI folder on the flash drive then it is set for UEFI boot. If instead it has a trailing tilde character then the flash is set for Legacy boot.

I would not bother as drives in good health should be able to take the load. There is also the fact that copying the data elsewhere would put just as much (if not more) load on the drives. Having said that, remember the parity is no substitute for backups - it is only about protecting you from disk failures (i.e. giving high availability). There are lots of other ways to lose data that parity will not protect you from. You should therefore always have backups of anything you cannot afford to lose. Many people do not bother to make backups of media files on the basis that even if the worse happens they could recover them even though it could be time consuming. It is up to each user to decide what trade-offs they are prepared to make for convenience v safety.

Just realised that I did not answer this bit. In this case the time to rebuild a drive is determined by the size of the drive being rebuilt (at the same 2-3TB per hour estimate as used for the parity build) so if the disks are smaller than the parity drives it does not take as long. Another way to look at it is that both processes involve writing to every sector on a drive so how quickly that can be done is the determining factor.

Yes in principle the number of data drives is not normally a major factor. However, If the extra drives on a disk controller mean its throughput capability is exceeded it slows the process down thus extending the time. In addition, very slow processors the overhead of calculating parity2 (which is a much more complex calculation than used for parity1 can also mean that the CPU becomes a limiting factor. I It is also worth noting that the process slows down as the inner tracks on drives are reached as their throughput is then lower (less sectors per track that can be read in a single disk rotation).

I assume the disk that should be disk3 is the one with WSD0QVWE as its serial? My guess would be that you disturbed its connection when adding the drives you now want as Unassigned drives. It is showing up OK in the SMART reports and it looks OK there. Does Unraid show that disk3 is currently being emulated? If so check that the emulated disk has the content you expect as the process for getting it back into the array involves rebuilding the drive with the contents that are shown as present on the emulated disk3 by stopping the array; assigning the disk as disk3; and restarting the array to rebuild the physical disk3 to match the emulated one. if the emulated disk3 does NOT show the expected content then do not rebuild but post back here for advice.

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

That looks as if no major corruption was found. You need to run without the -n option if you want anything to be fixed, and if it asks for it add the -L option. Restarting in normal mode should mean the drive then mounts OK. Look to see if you now have a lost+found folder - if not all data should be intact.

The time is determined by the size of the largest parity drive. Typically around 2-3 hours per TB as long as your disk controllers are not throughput limited. With modern large drives you are likely to find the Parity Check Tuning plugin will help with minimising the impact on daily use of very long parity checks.

This message has always occurred in all Unraid versions if the USB cannot be found at step 4 of the boot process (described here) but what is not clear is what has suddenly stopped the flash drive being found for some people. As far as I know this was not an issue for the many rc releases that preceded the ‘stable’ one. Not clear if this is a specific hardware combination causing this that nobody running an rc release happened to have, or if there is some last minute change since the last rc triggering it.

This could be a problem - Unraid v6 requires a 64-bit capable system.

No, Parity will be reflecting the current contents of the drive (including the lost+found folder). Parity has no knowledge of files - only disk sectors so in that sense it is not content aware. Parity is about protecting you against disk failure - it does not protect you from corruption at the file system level when the dixk has not failed. That is one reason that having parity protection is not a substitute for having backups outside the array.

Unfortunately not. Files get put into the lost+found folder when the repair process was not able to find their directory entry to figure out their name (in which case they are given a random numeric name) or where they belong in the file system. It is often easier to restore from a backup (if you have one) rather than putting in the effort required to sort out the lost+found folder.

Make sure that you make a backup of the flash drive with your current working setup in case you later get some unexpected behaviour.

You can always use the procedure described here to handle the upgrade if you are not able to do it via the GUI.

You could try this process to see if it helps

The diagnostics can help us see both what activity is happening, and also how you have things configured that might cause activity. They are not just about errors

It does not normally take very long (typically seconds to minutes) unless there is very severe corruption. The main determining factor is normally the number of files on the disk rather that the size of the disk. Why are you asking?

Have you tried clearing cookies/cache in your browser (or using incognito mode).