Squid

That’s why it’s happening. (Not that it should though). The problem should disappear if you upgrade to 6.9.2 @bonienl

What Unraid version?

You need to move the files from /mnt/disk2 to mnt/diskX or to an unassigned drive (or completely off the array) (do NOT move to /mnt/user as you'll corrupt the files) then change the format, reformat and then move them back. See also

Diagnostics might tell the story

You've got the cache floor set on what I'm assuming are the shares you're talking about as 0. So, if the system does not know the size of the file that is being transferred, it will fill up the cache drive until it errors out. If it knows the size of the file, then it will first check to see if it'll fit and then decide where to move it. Set the cache floor to be the size of the largest file you reasonably expect to ever be moved to it.

Thanks. Do this: Reboot the server into GUI mode, then from Windows, log in and try and start the array. If it fails, then from the GUI do another Tools - Diagnostics. What you're saying about it getting "stuck" doesn't really make much sense as fundamentally there's zero difference between logging in via GUI mode and remotely on another computer.

Unraid does not automatically format a drive. If the drive came up as unmountable either prior to or after the rebuild process, a popup would have showed up that stated that "Formatting is never part of a rebuild process". Did you tell Unraid to format the drive? This is what caused the problem. By changing the format of the drive, it basically would've had to format the drive. (But still would have prompted you) What you want to do is take a note of all the current drive assignments, do a Tools - New Config, and then reassign the drives and substitute the ori

Before you revert, from GUI mode can you grab the diagnostics (Tools - Diagnostics) and post them here.

Did you

And run a memtest from the boot menu if only to rule memory possibly out.

Buy either a Seagate or Western Digital drive. They look to be a rebranded Seagate based upon the smart attributes, but are definitely running custom firmware. Not quite sure if I'd trust a drive like that

I think the issues are due to changes at ookla (could be wrong though). Either way, I'm having CA mark 2018.02.11 as being incompatible as it doesn't work at all.

I've already submitted a fix for @limetech to consider.

If the system at the file level, not torrent level knows the size of the file before it begins to be written and the share is set to be use cache: prefer, then it will automatically put it onto the array. Since this is doubtful, you'd have to create another share set to use cache no (or temporarily adjust the existing share to be use cache no) and set the file to down load to it.