itimpi

Have you looked to see if you have a ‘media’ folder on the cache? This will give those symptoms even if there is no content inside that folder.

I would have thought the correct answer is 2TB for RAID1 profile, and the 3TB is the known issue of BTRFS reporting incorrectly with an odd number of drives?

The whole zip

This is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the UnRaid GUI.

just to point out that you can get scenarios where all sticks test fine individually, but you still get failures when all sticks are installed at the same time.

The diagnostics seem to indicate the array is running fine, so no obvious reason you should get that error message Only thing I can think off to suggest is to reboot but no good reason think that will fix things other than the fact it is often good practice just to confirm the error is persistent. maybe someone else will have an idea

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

This is basically a hardware problem in that the data being written to the mbr sector on the drive by the preclear process is not being read back correctly. You would expect a borderline sector to be re-mapped by the drives firmware but it appears this is not happening. Unraid will not be able to use a drive if the mbr sector cannot be written and then read reliably. There is a chance that using the use the manufacturer's tools might correct this. Not sure if there is any other way to achieve this so would be interested to see what others might suggest.

yes - but UnRaid have said that there is a chance that /mnt/user0 may disappear in a future UnRaid release.

you would not get this problem if you use a ‘copy’ operation. It occurs when you try and use a ‘move’ operation from the command line (or a Docker container) as the way Linux implements move can by-pass the UnRaid User Share system if Linux thinks both source and target are on the same mount point leaving the moved file on the same physical drive but in the new folder.

No idea - the GUI is not something I know how to look into.

It does not happen on my VM’s tab so I suspect there must be some other factor at play.

this is all covered here in the online documentation that can be accessed via the ‘Manual’ link at the bottom of the Unraid GUI.

Which shares are still showing this? If you only have a single device in a pool (cache) then this is to be expected for shares (e.g. appdata) that are set to be kept on the cache for performance reasons.

If you have acknowledged the error then it should not prompt you again unless the value changes. This suggests there is something else going on but I am not sure what. Maybe someone else will have a suggestion?

Here attached to a new post

It might be better if you posted your system’s diagnostics zip file (obtained via Tools -> Diagnostics) as they provide more information than the syslog (and also include the syslog). One thing I notice is that you have a very restrictive Split level and that might force mover to put files on a disk that has insufficient space (and thus fails).

You can also click on any drive on the Main tab and set a value that is specific to just that drive.

not quite! It will regularity be reading (and potentially writing) configuration information information. These reads/writes are only for very small amounts of data but can occu any time the GUI is in use. That is one of the reasons you cannot remove the flash drive while UnRaid is running.

Stop array Assign new parity disk Start array to begin building parity on that disk

If you manually run mover does this help fre up some space? Have you worked out what is using all the space on the cache pool? points I noticed: you do not have a Minimum Free Space value set for the cache pool. Ideally you should have this set to be larger than the biggest file you expect to copy (normal recommendation is twice that size) to indicate when UnRaid should stop trying to use the cache for new files. the Split Level setting for the ‘tv’ share is set to 1. This is very restrictive and may force UnRaid to try to move files to a disk that has insufficient free space as the Split Level setting takes priority when moving files via mover if they’re is any contention between share settings when selecting an array drive. This could result in mover being unable to move all files off the cache for the share. You could turn on mover logging to see if this is happening

either method will work for the SSD’s. If you want redundancy then use them as a single pool (albeit with only half the space) set up with the (default) of BTRFS RAID1. If you are going to run without redundancy then running them as separate pools makes some sense.

For drive1 run with the -L option for the repair toproceed as the warning is standard after a disk has been reported unmountable. for disk2 there appears to be a more serious issue that xfs_repair will not be able to help,with. Not sure why you would get this? Had you started the array in a maintenance mode?

Have you tried the procedure covered here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

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