trurl

Do you have an UPS?

If that different enclosure is still USB don't be surprised if you have more problems.

Parity can only rebuild disks in the parity array. And rebuilding from parity is unlikely to fix corruption on disks in the parity array.

That looks good.

Your system share has some files on the disk7. Maybe libvirt instead of docker image though. You might just check the contents of disk7 to make sure your docker image is on cache now.

Why not just make that share it gets moved to a cache-yes share? Assuming plex is only looking at user shares, then it won't know the difference, and mover will move it to the array according to its schedule.

Unraid definitely works with Windows 10 Home edition. But I don't understand why you would bring openVPN and duckdns into this at all. This thread is mostly about accessing your Unraid user shares from a Windows PC on your LAN. Are you having a problem with that? If not then explain your problem in more detail. I may move this part of the discussion to its own thread, or possibly split it into another support thread if appropriate.

Not clear what your first paragraph has to do with the second. If you could better explain the second paragraph maybe we could try to address this bottleneck.

Cache pool is raid1, so it is a mirror. None of your appdata is all on a single disk, but there are 2 copies of it in the cache pool. That's how I have mine, and in fact I recommend it. Why would you have ever put an HDD in a pool of SSDs? Sort of defeats the purpose of having any SSDs. Just noticed you have a cache6 assigned but nothing assigned as cache5. Is that right? I don't think formatting cache was the correct approach if you wanted to keep anything. I would sit tight until @johnnie.black wakes up, he knows the most about how to deal with cache pool problems.

raid1 is the default so if you didn't go to the trouble to make it anything else that is what you have. The reason I ask is because you may not have as much capacity as you think in the cache pool since its disks are of different sizes. https://forums.unraid.net/topic/46802-faq-for-unraid-v6/#comment-480420

Do you have any SMART warnings on the Dashboard for any of your disks? Do you have Notifications setup to alert you immediately by email or other agent as soon as an issue is detected? If you'll post your Diagnostics we can take a look and see if you have any problems you don't know about.

Your cache pool has 4 disks of different sizes. Is it configured as raid1?

Everything in Unraid is Linux. Do you mean you are using the linuxserver plex docker? Linuxserver is sort of a brandname for a group of docker developers.

You have set all of your shares to cache-prefer. Prefer means write to cache and never move them to the array. Normally only appdata, domains, and system shares should use the prefer setting, at least until you understand why you would do something different. All other shares that you want to use cache should be cache-yes so the files will be later moved to the parity protected array. And appdata, domains, and system shares are not all on cache even though you have them cache prefer. Probably you enabled dockers and VMs before you added cache, so those got created on the array. You need them to be on cache so your dockers and VMs will not be impacted by the slower parity writes, and so your dockers and VMs will not keep array disks spinning. Also, Mover can't move open files, so it won't be able to move appdata, domains, and system to cache where they belong unless you disable the Docker and VM services. Set all shares except appdata, domains, and system to cache-yes Go to Settings - Docker and disable the Docker service Go to Settings - VM Manager and disable the VM service Leave Dockers and VMs disabled until told to enable them again Go to Main - Array Operations and Move Now Wait for Mover to complete Post new Diagnostics

You will get an initial burst of speed until the RAM buffer fills then it will slow to the write speed of whatever disk is involved. Writes to the parity array are somewhat slower than the disk due to parity update. Haven't looked at diagnostics yet.

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post. I have split this into its own thread since that was an old thread about a different topic.

Linux uses RAM as I/O buffer, no way to disable that and I can't see any reason you would want to. Each user share has a setting for how it uses cache. The default for that setting is to not use cache. Have you changed that setting for any of your user shares?

Most likely bad connections. Check all connections, both ends, power and SATA, including any power splitters

No You can restrict a user share to specific drive(s) but if you give a user write access to a share they can write as much as they want, depending on included disks and the Minimum Free setting for the share.

I assume someone else set this up for you since you couldn't have gotten this far without logging in to the webUI. This message does not come from your server. Are you sure you are accessing the server? As Squid said, username root, no password, unless whoever set this up for you set a password for root. If for some reason you can't ask them for the password, come back for more advice.

Just remove all the .plg files then none of them will be loaded after reboot. Then you can reinstall the latest versions of just those you need and go from there.

Can you open one of them in a text editor or something?

We can work through your Fix Common Problems. If it's working with those, then just remove the other plugins until you can figure out which is the problem. Might just be you don't have them all up-to-date.

It is rebuilding the disk just like it would always do if you replaced a disk in the array.

Don't use USB in the array. The connections are likely unreliable anyway and will just cause more problems even if you could get beyond this one problem.