JonathanM

How are you determining that? SMART tests are a fairly good indicator, but you haven't posted diagnostics from your server so I have no way of verifying what you are saying. If parity is in sync, and all remaining drives are healthy, Unraid will emulate the missing disk exactly as it was at the point it was disabled, and all further operations to that slot will be done by updating the parity disk exactly as it would have been had the drive not been disabled. Normally to upgrade parity you would simply remove the old parity drive and replace it with a new one, or simply assign a new drive to the second parity slot if you wanted dual parity. No need to complicate things by going through a procedure meant for using the current parity disk to replace one of the data drives. Why would you do that? It's not necessary if what you want to accomplish is a parity upgrade.

Get a controller from this list that can handle all your drives and see if the issue is solved.

The answer depends on the condition of your array drives. Are all of the remaining drives perfectly healthy? When was the last time you completed a parity check with zero errors?

Are all your current array drives healthy? List your current drives, and then list your desired final configuration. I suspect you are overly complicating things. Parity IS NOT A BACKUP. The parity disks do not contain copies of your data. https://wiki.unraid.net/Parity

Long shot, but try the NUT plugin.

Why? Do you have it set to backup with CA Backup?

I've seen reports on the chia mining thread here on the Unraid forums that it's not needed or even advantageous to mine directly to SSD.

Passive cooling is completely dependent on the airflow patterns in the case. Since you changed motherboards, the airflow patterns have changed. Try temporarily forcing air over the HBA with an extra case fan, or run with the side off with a household fan directed inside. Note, running with the side off WITHOUT an extra fan blowing directly in is asking for trouble, as any case fans will likely just freewheel uselessly as their airflow bypasses everything it was meant to cool.

Do you have active cooling on your HBA?

Tools, new config, assign the drives where they go. Be VERY careful with the parity slots, drives assigned to them will be erased.

You can't judge a heatsink's performance by the temp of the heatsink, because it's possible the CPU itself is boiling hot but not transferring the heat. You've got to measure the CPU directly, the on die sensors are a good indicator.

I'm not saying it's faulty, but possibly not active with windows until the drivers are loaded.

I strongly recommend NOT doing this. What exactly are you trying to accomplish? There may be a better way of getting it done.

You can do a new config and assign disks to any data slot you want. The only disks that get erased with new config are the parity slots, so as long as you don't assign anything to parity 1 or parity 2 nothing will be erased. As you said, any disk you remove, the data will be unavailable on the array, so you must manually copy any data you want to keep.

Off the top of my head for a stock install, the flash drive on /boot, array disks in /mnt/disk(X), named pools in /mnt, docker image in /var/lib/docker, VM image in /etc/libvirt. Pretty much anything else is user added, like /mnt/disks/* and /mnt/remotes/* for Unassigned devices. Use the df command to see what all is available. Since /boot is FAT, there are restrictions because FAT doesn't honor all permissions. The mount points are available at different times based on what is started and what isn't, so if you need access without the array started you are limited.

What about the other ports on the card?

That's the best case scenario. If windows appears to run flawlessly with bad RAM, it's likely that there is file corruption happening silently in the background. It's much better for the system to halt at the first sign of trouble than to run like nothing is wrong while mangling your data. I'm convinced 99% of the reports of silent bit rot on otherwise healthy hard drives is caused by bad system RAM.

What IP and subnet did you set, and what was it changed to?

It doesn't / can't. If you use SMB shares, Unraid can intercept the action and move the files correctly. Since you are using Krusader (a container) to directly access the /mnt/user tree, it can't intervene, and since a rename works correctly as far as Krusader can see, it doesn't do the copy / delete.

Any error can be fatal. You must suspect any file that touches a system with bad RAM, as it's practically impossible to know whether or not it has been silently corrupted.

How do you do the manual move? Try copying then deleting the source and see if the results change.

Which share do they download to, and which pool is it assigned to?

Cool. That paints a much more compelling picture for changing it out.

FYI your Unraid license is tied to the physical stick, and you are only allowed 1 automatic transfer per year. So, you can never use the original stick for Unraid again since it will be blacklisted after the license is migrated to the new stick, and if this stick dies and you need another transfer before the year is up, you would need to talk directly to support and explain your situation. Given that, I advise people to not transfer licenses to new sticks just for the fun of it. What's done is done, but I personally would have given the old stick another chance, while keeping your flash backups up to date.

Do you have a current flash backup? The odds are not good that it will come back up without help. When you do get to that inevitable point of shutting down, try your best to stop everything normally, including stopping the array itself. If you force a shutdown with array disks mounted you run the risk of parity not being in sync.