JonathanM

Thank your lucky stars that you didn't blow up all your drives. Modular cables are not always compatible, EVEN from the same name brand. Unless you know how to operate a volt meter and test the pinouts before powering your drives, NEVER reuse modular cables with the different PSU, just keep them together as a set.

Fingers crossed that it will actually perform better than wired in real world testing. I have yet to see a scenario where wireless was faster and more stable than wired outside of a controlled lab environment. Random RF attenuation and interference cripples every real life longterm install I've ever seen. Wireless works, yes, but wired still has its place.

Does either your existing broken hardware or the new hardware use any RAID controllers? Are they in IR mode? Are you passing through any hardware to VM(s)? If the answer to all of these questions is no, then there is no action needed. Simply move all your data and pool drives to the new hardware along with the boot USB drive and it should boot up seamlessly.

yes not relevant if you read this thread.

There are multiple methods to get a wifi signal converted to ethernet for Unraid. If you really want to use Unraid, integrated wifi support is not the show stopping obstacle.

Both halves of the mappings must match. At the moment, you have /data on one, and /downloads on the other. Change all the /mnt/cache/Downloads mappings to the same thing, whether it's /data or /downloads doesn't really matter, just has to be the same for all the download clients.

Possibly reseating them solved it. You need at least a full pass with zero errors on whatever configuration you plan to run long term. I suggested the single stick test to best prove or disprove that the RAM itself was the culprit, but sometimes motherboards can run single sticks with no issue and still have problems with the power load of multiple sticks.

What result do you get when you ping your duckdns name?

No point in continuing the memtest, any errors are fatal. Check CMOS memory timings, make sure there are no XMP / overclock settings, if needed manually set all the timings. Rerun memtest, if errors continue, test single sticks. If single sticks all pass, then possibly motherboard / PSU issues. DO NOT ALLOW any data to be read or written to the drives until memtest is all clear.

Keep regular backups of the flash drive in case it quits for good.

Attach the diagnostics zip to your next post in this thread if you want more accurate advice, but given what you have posted, you need the parity swap procedure. The size of the cache drive is irrelevant, but the parity drive(s) must be as large or larger than any single data drive in the array. You are planning on attaching the new drives directly to SATA, not USB, right?

FTFY. Encryption makes file system corruption data recovery almost impossible. If you care enough about the data to encrypt, you MUST first have a tested backup plan in place.

If you reboot after deleting through user shares, is the file gone?

Because there is no good universal location to log to, every situation is slightly different. The only universal location that is guaranteed to exist is the flash drive itself, and that is a very poor choice for a logging location as all the constant writes put much wear and tear on the licensed USB. Probably the best option is to send the logs to a SSD, but not everyone uses one in their server, and the path can be different for any given install. If you do choose to log to the boot USB, be sure to turn that off as soon as you can.