itimpi

In many cases the overall Passed status is meaningless. It only changes if one of the attributes has a “Failing Now” status. The one that is the best indication of drive health is the Extended SMART test. If this cannot complete without error then you should be replacing the drive.

Because the appdata share is set to Use Cache=Prefer which means that you want the files to be on the cache if at all possible (Use Yes for shares you want moved to array). You normally want the appdata share to be on a pool for performance reasons so you probably want the downloads to go to a different share that is set to Use Cache=Yes and the mappings for the sabnzb container amended appropriately.

A drive needs to be formatted by Unraid before it can be used for storing data. If you did not find format then you probably did not look hard enough as there is always an option to format unmountable drives under Main->Array operations. You should always check, though, that no drives showing there are thought to have data as the format operation wipes any existing data on the drives.

Your cache seems to be full of files that you have configured to be on the cache so there is nothing for mover to do. Look like you need a larger cache pool to hold the files you have been configured to be there. You can use the compute button on the Shares tab to see both how much space each share uses and on what drives. Also you have not set a Minimum Free Space value for the cache pool. This is necessary to tell Unraid when to start putting new files onto the array rather than the cache.

There is a good write up on New Config 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.

The only way I can think of is: Use Tools->New Config (with Preserve all assignment) Return to the Main tab and put the 14TB in place of the 18TB. Leave the 18TB unassigned at this point Start the array to build new parity based on the 14TB drive being in the array Format the new 14TB drive to get it ready for use Mount the old 18TB drive via UD, and copy its contents back to the array. Once all the data has been copied off the 18TB drive it is now ready to be assigned as parity2

If you boot in UEFI mode then the version of memtest included with Unraid is incompatible. In such a case you should download a more recent version from memtest86.com that is compatible with UEFI boot mode. You are likely to get more informed feedback if you include your system's diagnostics zip file attached to your next post in this thread.

The diagnostics show corruption on the cache drive (and the docker image file). Why I am not sure and do not know the best way forward.

Have you tried rebooting? If not then I suggest doing so and if the problem persists post new diagnostics taken after the reboot. Another issue is that you not on the latest Unraid release and the one you are on has a bug that does not give us much information on shares in the diagnostics.

The share configs ARE stored on the flash drive. What shares are missing?

I am confused as your question does not really make sense I think I must be missing something? A User Share is just a combined view of the top level folder corresponding to the share name across all array drives and pools. It is not tied to the cache drive in any way. You still seem to have share configuration files intact so in that sense the information for them is still there. If you meant you have lost the content of the parts of the shares that were on the flash drive then unless you have backups elsewhere that content will be lost.

You seem to have at some point created a User Share called 'Cache' which is the cause of your problem and is why the system will not let you create a pool called 'Cache'. The cache.cfg file you posted is that for a User Share - not that for a pool. Since this share does not exist on any drive at the moment you can delete the config/shares/cache.cfg file from the flash drive and then the system would let you create a pool called cache.

The official documentation is quite well structured, so starting at the top level of that and descending into the section of interest will normally find what you want without the need to go through a search. The official documentation is not open to everyone to edit and is complete and accurate in most areas on topics that regularly come up.

the worst the -L option will do (if anything) is remove the last changes to the drive.

With parity disks of that size you may well want to install the Parity Check Tuning plugin to help alleviate the impact/pain of very long parity checks on day-to-day running.

You can add both at once if you want and the building of parity on them will run in parallel. In terms of time assume something like 2-3 hours per TB with the total time dictated by the largest parity drive (if not the same size).

You can transfer directly to a given drive if you have Disk Shares enabled. They will only be unprotected if you do not have a parity drive as if you do then parity is still updated in real time as you write to the drive. If you are writing to multiple drives like this and have parity assigned then you still want to avoid multiple streams at the same time to avoid contention on the parity drive. WARNING: Never mix a disk share and a user share in the same copy/move command as this can easily lead to data loss.

That message is quite normal as described here in the online documentation describing the process for repairing an XFS file system. You need to run without -n and add -L.

The entries in List+Found always tend to have cryptic names. However in the case of folders appearing there the contents of the folder often have their correct names so you can work out what the folder name should be.

Reiserfs cannot handle drives larger than 16 TB (one of the reasons it is now deprecated) so that may be the cause of the problem. For drives of the larger sizes now available you need to use XFS or BTRFS (or ZFS when Unraid 6.12 is released) as the file system type.

Normally you just put the licence file into the ‘config’ folder on the flash drive and boot Unraid. Unraid will then tell you that the licence file is wrong for this flash drive. As long as you have not done it already in the last year that takes you through the automated licence transfer process. If you HAVE done it in the last year you need to go via the support route.

The general rule of thumb is something like twice the size of the largest file you normally expect to write to the share. Another thing to think about is that if for any reason you get file system corruption on the drive it is a good idea to have something like 10-20 GB free for the check/repair process to use.

That is what I would expect because that setting means you want the final resting place for the files to be the main array.

One should always start from the Documentation link on the web site or the Manual link in the Unraid GUI. That way you are more likely to get the current documentation. The current online manual is quite reasonable.

You might also get away with simply setting a value on the cache pool for the Minimum Free Space option that is larger than the downloads you will have running at the same time.. Shen free space drops below that then new files will automatically start by-passing the cache.