itimpi

Does the .cfg file for the share on the flash drive now have the same case as the folders for the share on the array/pool drives? Suggest you post new diagnostics so we can see the current state.

Does not sound like you tried what I suggested by clicking on the leftmost icon on the boot device (flash) on the Main tab.

You need to navigate to the flash drive manually using Unraid's build-in File Manager by clicking on the left-most icon for it on the Main page and then navigating to the config/shares folder. From there delete the existing .cfg file for the share. The problem is arising because Linux is case sensitive for file names whereas the FAT32 file system used for the flash drive is not (although it is case-preserving once a file is created).

Your question does not seem to make sense as if the 2 drives are in a pool there is no concept of primary and secondary. Perhaps you need to clarify what you mean. In addition files should only ever be at a single location as far as Unraid is concerned. As a result mover will not overwrite an existing file that is on both primary and secondary storage if you have manually created a duplicate filename in some way.

I doubt that this going to change, but remember you can always use the classic manual upgrade (or downgrade) facility that completely bypasses the GUI.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to the problem. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field and log to a share instead.

Writing to a flash drive will normally be OK as long as you only do it for a limited amount of time. It is only not recommended as it puts load onto the flash drive that can increase the likelihood of it failing. I have done it myself a number of times but then I am using an oldish USB2 flash drive that is less prone to failures of this sort than modern USB3 ones seem to be. If it is not the Unraid boot flash drive then the worst that can happen is the flash drive fails. Another possible option that you have not mentioned is a HDD or SSD/NVME connected via a USB adapter or dock.

That plugin cannot check integrity of files added before the plugin was installed. It can be set automaticallygenerate checksums for new files, and can also create checksums for existing files based on their current contents.

No. There is no fault tolerance with Unraid for any sort of single disk pool - you need to go multi-disk for that. A single disk btrfs pool can only report which files are corrupt - it cannot repair them.

Parity is never held at an individual drive level but is always system wide. If the emulated drive is mounting OK and the expected files are showing then after a rebuild parity should be good as all drives plus parity drive are involved in a rebuild. If the expected files are not showing then a rebuild is probably not the best next step. After a rebuild it would not hurt, however, to run a parity check at that point although it is probably not needed as it should be correct.

You should definitely not rush into rebuilding disk1 as parity may no longer be valid after getting all those read errors. As you say there is a good chance that the data on disk1 is actually all intact if it dropped offline due to a controller issue. Have you tried a power off/reboot sequence to see if the disk controller is recognised OK? You are likely to get better informed feedback if you attach your system’s diagnostics (with everything in the one zip file) to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

No point in continuing the Parity Sync if you are getting read errors on the data drives.

par2 is not about keeping checksums for each individual file, but about protecting a file set and providing recovery data for when files in the set are damaged. Note that checksumming does not in itself give recovery capability - it merely allows you to identify damaged files. The checksums are stored as file attributes and effectively consume no additional space. You still need to recover damaged files from backups.

ZFS is not recommended for use in the main Unraid array as it does not perform well when used there (this does not apply to ZFS used in pools). Whether this will be solved for a future Unraid release I have no idea. If you want to switch to a checksumming file system in the main Unraid array then BTRFS would make more sense. Having said that XFS is still the preferred file system for the main array as it is deemed more robust against failures. There is the File Integrity plugin available if you want checksums kept on a XFS system. In all cases you should still have backups of any important data.

The sector numbers are given in the syslog, but there is no way of knowing which drive caused the issue or which file(s) may be affected. The only way to check data integrity if using XFS as the file system for array disks is to have checksums for the files previously generated using something like the File Integrity plugin. If you had been using btrfs or ZFS then these file systems have built-in check-summing so could identify files affected. Even with these you would still have to restore good copies from your backups.

If it is not capturing anything you may have syslog configured incorrectly. I suggest you post a screenshot of the settings you have for it.

If you do not want to disable the cache as @door-to-door-oddball3058 recommended, then at least make sure that you have a sensible value set for the Minimum Free Space for the 'cache' pool to stop it filling up too far. When the free space falls below this value then Unraid will start bypassing the cache for new files and instead write them directly to the array.

@foo98 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 and configuration information.

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 and configuration information.

This (less the old licence.key file as you will have a new one for the new USB stick).

I do not not think that un-blacklisting is supported, so I expect you will need to transfer licence to new drive. Be interested to know if support say otherwise.

When you say "3 in the pool" then I assume you mean the main Unraid array (which is what your screenshot says). Note that the term 'pool' in Unraid has a special meaning for disks that are not part of the main Unraid array. If that is the case you need to remove the 'cache' and 'pool' pools as they do not have any drives assigned where your screenshot suggest they should have one each.

As long as you have a valid paid-for licence you can always download the zip file for a release and then use the Manual update method.

You need a flash drive that has never been used before for Unraid and that also has a unique GUID. As was said if in doubt contact support.

It is worth checking if any of the files that will not move are actually duplicates as Mover will not overwrite existing files. If you have duplicates you need to manually decide which Copy to keep (typically the newest) and delete the other copy.