itimpi

Why would you want to do this? Legacy Pro (which is not available to new Unraid users) is identical to Unraid Lifetime and there is a (much cheaper) upgrade path from Legacy Plus to Legacy Pro.

Yes. The same also applies to BTRFS drives (which perform better) when used in the array.

Not unless you have the original 2TB drive which may still be recoverable.

No point - the format you did also updates parity appropriately to reflect an empty file system, so that the repair will just be checking the new file system you created.

Fair enough - but doing the check filesystem instead of format at that point would probably have recovered the data (and then extended the file system to 4TB).

If you formatted the drive during the rebuild process then its contents will be lost and it will be rebuilding an empty file system. The correct handling would have been to run a check filesystem on the drive. We normally recommend doing this before doing the rebuild. If you still have the drive that was replaced intact then you may still be able to get the data off that.

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. A screenshot of your VM settings would also be useful as that sort of information is not included in the diagnostics.

Normally only a few hours - but remember that support is on US time. Did you get an automated email response when you tried to contact support? I not then the support request may not have gone through and you should try again.

I cannot tell from the picture but are you using a power splitter? If so be aware that a SATA->SATA connector cannot be split reliably more than 2 ways - you can get 4 way reliably with a Molex->SATA splitter

Since the issue normally indicates a problem reading files from the flash drive then if rewriting the flash drive does not help and since you get the same behaviour with two different flash drives and you do not think you have a RAM issue then it is possible you have a dodgy USB port.

That will be because radarr is trying to ‘move’ them to the ‘media’ share, but because of the behaviour mentioned in the Caution they remain on the cache pool. If radar had instead used a copy/delete strategy they would have ended up on the array as you expected.

The SMART information for disk8 looks OK but if you want to do a confidence check run the Extended SMART test on the drive. More often than not read errors are due to cabling issues (either power or SATA) so check those carefully.

Do you have VM support enabled? Those shares normally get created when you enable support for VMs

I suspect that the docker.img file sued to hold your docker container binaries was also on the cache drive and so removing it made them disappear! If you post your system's diagnostics zip file we can confirm, if this was likely what happened. If it was then it is easy to recover from that.

I get the same behaviour after updating the calibre container to the latest version so I strongly suspect the issue is something wrong with the container itself. I can open a console session, but not a GUI one.

Your sysl;og is full of errors of the form: Jul 29 14:02:01 Sith kernel: BTRFS error (device nvme0n1p1: state EA): bdev /dev/nvme0n1p1 errs: wr 0, rd 270833, flush 0, corrupt 0, gen 0 Jul 29 14:02:01 Sith kernel: BTRFS error (device nvme0n1p1: state EA): bdev /dev/nvme0n1p1 errs: wr 0, rd 270834, flush 0, corrupt 0, gen 0 Jul 29 14:02:01 Sith kernel: BTRFS error (device nvme0n1p1: state EA): bdev /dev/nvme0n1p1 errs: wr 0, rd 270835, flush 0, corrupt 0, gen 0 Jul 29 14:02:24 Sith kernel: BTRFS error (device nvme0n1p1: state EA): bdev /dev/nvme0n1p1 errs: wr 0, rd 270836, flush 0, corrupt 0, gen 0 Jul 29 14:02:24 Sith kernel: BTRFS error (device nvme0n1p1: state EA): bdev /dev/nvme0n1p1 errs: wr 0, rd 270837, flush 0, corrupt 0, gen 0 Jul 29 14:02:24 Sith kernel: BTRFS error (device nvme0n1p1: state EA): bdev /dev/nvme0n1p1 errs: wr 0, rd 270838, flush 0, corrupt 0, gen 0 which shows that the cache_downloads pool is corrupt. @JorgeB is probably the best person for giving recovery advice. Since corruption of btrfs file systems is frequently the result of RAM issues have you recently run memtest from the Unraid boot menu?

I suspect that this is the cause of your trouble if radarr is trying to use a linux level move command to transfer files to the 'media' share which is by-passing the Unraid Share level and leaving the file on the cache in a 'media' folder. As I said the easiest workaround is to simply to set the share up as I described so that Unraid thinks the file is being cached and mover will later transfer the files to the array.

If you think the Caution applies then you either need to correct whatever app is causing the issue so it no longer causes it or (probably easiest) set the share up so that it is Primary Cache: Secondary Array : Mover cache->Array so that the files later get transferred to the array.

Chances are that you are falling Gould of the behaviour described in the Caution section of online documentation here

I must admit that I had not thought of using WSL, and most Windows users are probably unfamiliar with it as they do not know Linux (and WSL is not installed by default). In the past I have used software from Paragon which has Linux file system drivers for Windows to allow me to read Unraid disks on a Windows system. On doing a quick check it looks like WSL should he able to handle XFS and BTRFS file system formats (although I have not tried it). ZFS and ReiserFS as the other two file systems widely used on Unraid (although ReiserFS is now deprecated) are not mentioned as being supported.

Not unless you have software (non-standard) on Windows to read Linux file systems. Perhaps you are getting confused with the fact that Unraid drives are readable on any Linux system. Having said that the Unassigned Devices plugin on Unraid does allow for none-array drives with other file system types that ARE readable on Windows/Mac systems.

The configuration details when you install a container are stored on the flash drive. It sounds as if you installed this container after the backup so there are no saved settings for it which is why you got the message. To fix it you would need to reinstall it using the previous settings if you can remember them.

What is this share? t--p shareUseCache="only" # Share exists on cache, disk2, disk3, disk4, disk5, disk7 It is set to only be on the cache for new files but has existing files on the main array. You might get a more useful pointer to where space is being used if you use something from the command line like du -h -d2 /mnt/cache

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread (which can be done from the console after logging in). 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.

The licence is tied to the USB stick that is used to boot Unraid - not to the hardware it is running on.