itimpi

That is probably because the md type devices only get created on array start. Have you actually tried starting in Maintenance mode as that does not mount the drives so I would be surprised if it checked any LUKS headers but it does create the md type devices.

That shows that most of the space is taken by the /tmp folder. You should look inside that to find the culprit.

Well you can have up to 30 pools each with a large number of drives, so if you use that technique you can attach something of the order of 900 drives with current Unraid releases. With support for ZFS in pools users may be inclined to think of doing that when they want large numbers of drives.

Did you check there is no folder for the share on the ‘cache’ device (even if it has no files) as that is sufficient to trigger the warning.

You could simply browse the 'cache' pool by clicking the folder icon to the right of the entry on the Main tab. FYI: You are meant to add an entry to the thread for an existing plugin in the Plugin Support forum - not try and create a new thread.

It is the Unraid OS. Rsync will not know which drive a file is on if you are writing to a User Share. Note that Unraid never moves files between array drives. The Split level setting is applied to new files at the point the file is first created.

If a torrent file is initially created without all the space allocated so that it takes additional space as more parts are downloaded this could be a problem as Unraid will not move the file to another drive in such a situation. It might be worth telling the torrent downloaded to allocate all the space needed for the file at the start to see if that helps alleviate the issue.

You should not be losing any data so something else must be going on.

It might be worth swapping the network cable?

Unraid does not support the traditional RAID levels on its main array (hence the name).

This drive should definitely be replaced. A small number of reallocated sectors is not unreasonable as long as the number remains stable, but a large number are a cause for concern. On a new drive I would be concerned if the number was not 0. FYI: not sure how you set the font but it is virtually unreadable when the forum is set to use the Dark theme.

What is doing this mount? Whatever is doing it will be hiding the normal contents of /mnt/user which is all the user shares.

It would be easy enough to try and mount it manually in the go file and only if that succeeds copy the keyfile across. If that fails, then without the encryption key the array would then not autostart.

One thing it might be worth trying if you have access (even temporarily) to a Windows machine is to format the flash drive using Rufus.

This is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. once you have gotten the drive out of the array you follow the standard procedure for adding a parity drive.

Yes

Not quite - parity2 will remain as parity2 and you will have no parity1. The calculations for the two parity drives are completely different so they are not interchangeable. It is perfectly valid to run without parity1 so in that sense parity2 remains valid. regarding step 4 then yes parity remains valid.

Your maths is not that good 10x28GB = 280GB.

That will not work as Unraid will still think you have a drive in the position of the 'removed' drive. The process to follow is documented here in the online documentation.

Are you trying to boot using legacy (CSM) boot or UEFI boot? For UEFI boot you need to ensure the EFI folder on the flash drive has no trailing ~ (tilde) character.

Unraid can detect drives that have been previously formatted by Unraid as described here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

It might be worth downloading the zip file for the release from the Unraid web site and then extracting all the bz* type files overwriting the ones on the flash drive. This seems to sometimes help with such scenarios. Do you have a monitor attached to the server so you can see what is happening when you try and boot?

The format achieves nothing as Unraid is going to overwrite every sector on the drive when you add it thus destroying the results of the format.

Had you disabled the docker and vm services before running mover? These services hold files open which would prevent mover transferring them.

Are you sure you are talking about the Parity Check Tuning plugin because: The plugin does not restart from the beginning for each increment. It continues from the point already reached when starting the next increment. This is repeated until the whole parity drive has bedn checked. The plugin has an option to restart from the point last reached after a reboot (as long as the shutdown as a tidy one). This caters for those who want to shutdown their server overnight or those who have regular power cuts (as long as they have a UPS so that the clean shutdown can be achieved). iI looked into using size increments instead of time ones but although technically possible this proved not that useful in practice since the speed can be affected by many factors so the time for a given percentage of the parity drive could vary significantly. Time based increments proved far more practical and it is easy enough for users to work out how many increments a full check takes if they run a similar length increment each day.