JonathanM

tools, new config, save all, main gui page, unassign drives you want to remove, start array to rebuild parity without them. Do NOT select parity is already valid, it is not, it must be rebuilt.

Soon™

Docker run commands for each of the containers, be sure to redact any credentials.

Floating grounds are bad, mkay? Plug the UPS into a switched outlet or power strip, then turn off the power to it without breaking the ground connection. Chances are high you will get away with just yanking the cord, but the possibility is definitely there to create a very large voltage differential across cords still plugged in to the UPS, for example the USB lead. This could blow out the USB port. Many years ago I personally fried a surge protector plugged into a UPS output when I yanked the supply out of the wall to demonstrate how good my UPS was. Rather embarrassing, but I was really glad the only damage was the surge protector, not the connected equipment.

Formatted is NOT blank, it has an empty filesystem with all the table of contents and file metadata structures ready to accept files. Parity doesn't have any concept of files, or any format for that matter. Moving files around on array disks doesn't invalidate parity as long as the array is started.

@SpencerJ?

If you don't mind my asking, where exactly did you find this? It's all kinds of wrong. A correcting parity check will make sure the parity is in sync. Assuming you ran the file system checks using Unraid's GUI, there is no reason to assume parity is out of sync, as all operations should have been done on the mdX devices.

Probably not, but that depends on if the disks have a standard partition layout and a file system that Unraid can read. In NO case I can imagine can they be put into the main array without losing data. If it is a healthy RAID1 and you don't mind breaking the mirror you could always see if one of the disks will mount using the Unassigned Devices plugin. Worst case you would need to put the disk back and allow the WD NAS to rebuild it. If either of the drives isn't perfectly healthy this very well end up with data loss. I wouldn't test this unless you have a full backup of any data you can't afford to lose. If Unassigned devices can't mount it (probably not), I see no other option besides copying over the LAN. BTW, Unraid (or any RAID) is not a substitute for backup. It can only rebuild a failed drive, it can't uncorrupt data or fix deletion. I'd copy the data and leave the old NAS as a backup destination.

Are you in bridge mode?

Test the new RAM before booting Unraid. New does not always = good.

Some drives are incompatible with the metal clips, and the clip cables tend to NOT have the required internal retention features. https://support-en.wd.com/app/answers/detailweb/a_id/15954/kw/Clip Jam 8gb MP3 not working/related/1

Copy instead of move will speed things up considerably, since move is a copy followed by a delete, it thrashes parity extra hard as the deletes are processed on the source disk at the same time the new data is accounted for on the destination disk. Since you will be formatting the source disk anyway, forgo the move and just copy. You also can compare the result to be sure the copy is complete before doing the format if desired.

Look for an LSI on the recommended controller page, most 8i models are available with 4i/4e, the newer cards may use a different external cable instead of 8088, in which case you would need that cable to 8087 bracket, the bracket can be generic. You can get really fancy with the power switch using special boards, or you can simply force the power supply on whenever it has external power and make sure you turn the external drive cage on first and off last when booting the computer.

That is the wrong metric to use if long term reliability is important to you. The boot stick should be inside the server anyway, where it can't get damaged or removed. If you motherboard doesn't have a normal USB port internally, it almost always has pin headers that use a cheap adapter to convert to a normal USB port.

Are you sure the processor is the bottleneck? Slow disk I/O is more common.

The second case only has the expander and the internal to external slot adapter. No motherboard. Just power supply, expander, adapter, drives, and a way to switch on the PSU.

What exact path are you downloading to inside deluge?

You probably aren't getting any answers because I don't think the question as asked is answerable. Passthrough is not typically about the specific card, it's more about the motherboard, BIOS version, chipset, and CPU. If passthrough fails with one card it's unlikely to succeed just with a different card.

Not without a bunch of hassle. The VM would have to be shut down, the passthough status changed, then if it's in a file system that Unraid's Unassigned Devices plugin understands, it could be mounted and read. Then the whole process reversed to allow the VM passthough to work. That may be the path of least resistance.

Yes on both counts. Be aware that vdisks are sparse by default, so don't overprovision without being acutely aware of the space actually in use. It's too easy to create a 1TB vdisk image on a disk with less than 1TB of real space available, and when the VM tries to allocate more than it can actually write to because the vdisk can't grow, it crashes the VM. Better to under allocate and move the vdisk to a larger space and reallocate as needed later. Backing up vdisks while the VM is running is tricky, as it's likely the file system as it appears to the VM may not be in a consistent state and a restoration from that state may require file system check and repair. If the VM is shut down, or the volume in question is unmounted inside the VM if it's a not a boot or system required volume, then it's no longer an issue. I'm not familiar enough with macos to know whether it's possible to release a mounted volume while the OS is still running. Depending on which type of file system the vdisk.img file resides, it should be possible to use snapshots in the host as well.

Not a dumb question, but I think you have 2 strikes against this scenario. The state of apple software as a VM doesn't seem very healthy, I think the latest CPU type change in genuine hardware has caused issues with virtual machines. I've not stayed up to date on this, but from what I've noticed in the forums you should investigate the feasibility of even running a VM. Second issue is one of general architecture, not specific to apple. A shared folder is controlled by the host doing the sharing, the guest passes requests that the host honors or not, any conflicts between possible multiple guests are resolved by the host doing the sharing. When the application requires exclusive control of the storage, it can't be on a shared resource.

Have you tried all the different USB ports on the motherboard?

Depends on what you are running. Much of the base file server functions seem to be single thread, but containers and VM's can use multiple cores to great advantage.

Only the expander and drives go in the second tower. The LSI controller goes in the main tower. That will require either running cables meant for internal case use from one case to the other, or buying a pair of the cable converters. If properly protected it would be ok to do the internal style cables, but it will mean partially disassembling one or both of the towers to get to the internal connections if you want to move things around. The e connections are exposed to the outside of the case in a slot, so much easier to unplug and move if needed.