trurl

Rebuilding is required because the disabled disk is out-of-sync with the array. Just enabling it without rebuilding will not fix the out-of-sync. The only other possibility is to rebuild parity instead so everything is back in sync, but since it is the disabled disk that is out-of-sync it usually makes more sense to rebuild it.

unBALANCE is about disks, mover is about user shares. unBALANCE moves from specified disks in the array to other specified disks in the array. Mover moves user share files from cache to array or array to cache based entirely on the settings of each user share. Each user share's settings controls which disk the files wind up on.

That diagnostic is without the array started so can't tell anything about the emulated disk3. Start the array and post a new diagnostic.

Go into your BIOS and set SATA controller to AHCI (currently using IDE mode) and try rebuild again

Parity is not a substitute for backups, whether Unraid or any traditional RAID. All parity allows you to do is rebuild a missing disk. Other reasons for data loss are much more common than failed disks, including user error. It's not a question of disabling trim for array disks because it is not enabled. It is simply a fact that SSDs in the array cannot be trimmed.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread. These words do not belong together and suggests you are considering making a VERY BIG mistake. Don't do anything without further advice.

Are you referring to the fact that parity and disk1 are disabled? They are being emulated until rebuilt. Looks like emulated disk1 is mounted so that's good, and since you have dual parity you can rebuild both. Since you rebooted nothing in syslog from when the problem occurred. No amount of messing with the hardware will re-enable a disk.

Don't understand what you mean by "without parity". Parity disk seems to be OK and not disabled. If you corrected parity errors you must run another parity check to verify. Exactly zero parity errors is the only acceptable result and if you didn't get that on your last parity check you aren't finished. See if there is anything useful for you in this thread:

Unless you have some specific reason to suspect a specific data disk, such as immediately after a data disk rebuild, you have no choice but to correct parity.

One more bit of encouraging information, though not sure it definitively answers the questions. From the diagnostics emulated disk3 is mounted, so that would seem to indicate that rebuilding disk3 from parity should be successful.

And also no reason to remove unless you intend to replace it with a different disk. Still trying to decide whether or not to believe in parity or not. I filtered out a lot of that. So the scheduled parity check was configured to write corrections to parity. Did you let it complete? Apparently you rebooted after that scheduled parity check Oct 1 22:48:06 baconator kernel: Linux version 4.19.107-Unraid (root@38721b48cdfb) (gcc version 9.2.0 (GCC)) #1 SMP Sun Mar 8 14:34:03 CDT 2020 no indication of an unclean shutdown, but another parity check started soon after the reboot. Oct 1 22:50:58 baconator kernel: mdcmd (45): check Oct 1 22:50:58 baconator kernel: md: recovery thread: check P ... Did you do start that one? Was it also a correcting check? Or was it actually rebuilding parity? Still ongoing 9+ hours later Oct 2 08:00:01 baconator root: Parity Check / rebuild in progress. Not running mover Then lots of read errors on disk3, finally the write errors that disabled it. Possibly Unraid tried to write the calculated data back to the disk it couldn't read. And finally it stopped itself. Oct 2 12:48:51 baconator kernel: md: disk3 read error, sector=10938752032 Oct 2 12:48:51 baconator kernel: md: disk3 write error, sector=15780546472 ... Oct 2 12:49:27 baconator kernel: md: recovery thread: exit status: -4 My inclination at this point is to not believe in parity, but instead do New Config, and rebuild parity instead of rebuilding disk3. After you have fixed your hardware, of course. The main problem with that idea would be if disk3 was corrupted somewhere along the way but that should become apparent immediately when starting the array. Or you could New Config without parity initially just to check if disk3 mounts, but not sure there would be much point since parity would definitely be out-of-sync that way. If there was disk3 corruption that could be dealt with separately. The SAFEST approach would be to rebuild disk3 to a new disk and save the original disk3 and decide later which version of disk3 looked the best. Of course, that would require another disk. See if there is anything else you would like to add, and maybe wait to see if someone else has a different opinion or approach.

Yes

You did mention that. Removing and formatting is totally unnecessary. Formatting outside the array would be totally pointless before using the disk for rebuild since rebuild would completely overwrite the disk regardless of how it was formatted. In Settings - Scheduler - Parity Check, there is an option to write corrections during the scheduled check or not. The usual recommendation is No. Check that setting and let us know and also what time the check is scheduled to start. I'm trying to sort through syslog to see but a lot of nvidia related spam in there.

Never tried it any way where Unraid was not the one with the open port, clients don't need any. Maybe ask on the Wireguard thread.

Once you get Unraid booting the first time you don't need graphics. Many of us run headless and just manage our server with the webUI over the network. I never have a monitor attached after I get the build working.

I get scared whenever anyone mentions format in the same post as rebuild. No need to remove and certainly no need to format. Especially important to NOT format with the disk in the array. Was it a correcting parity check? Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Open port to your Unraid server, Wireguard clients on devices that need access

You should setup the builtin Wireguard. It works without the array started.

Are you sure your server can reach the internet?

You must start the array in Maintenance mode to run repair. Don't see it in SMART though. Maybe try rebooting

I don't have a button but I am running the recent beta. What version does your friend have?

Does it crash as soon as you start the array, or will it crash whether or not you start the array? If it doesn't crash until you start the array (all disks spinup), are you sure you don't have a power problem? Have you done memtest (on the boot menu)?