JonathanM

Click on the VM icon and select remove.

Is your monthly check correcting or non-correcting? If it's correcting, run a non-correcting check to be sure everything got back in sync. If it's non-correcting, run a correcting check followed by a non-correcting to make sure it's done. All this presupposes all your current drives are perfectly healthy.
 
If you don't know how to be sure of what I'm saying, attach diagnostics to your next post in this thread.

6.12 is still in RC phase, so you need to select the next branch instead of stable.

I use UrBackup for my local workstations, and a handful of remote machines as well. It handles windows and linux clients.

Use the webGUI

Unraid doesn't require it, but some motherboards halt before booting if no graphics chip is found. Some of those motherboards do have a setting to boot regardless, but you need to be able to get into the BIOS setup to make the change.
 
How do you know the motherboard is actually set to boot from the Unraid USB stick?

Random(ish) errors after adding a drive are typically caused by power issues, either poor connections or lack of capacity to service the extra load. Parity checks are a point of maximum power use, especially when first initiated and multiple drives are spun up.
 
A high resistance connection caused by a splitter can also be an issue, as it causes a voltage sag under load.

Corrupt filesystem?

Safari is known to be randomly problematic for some subset of folks.
 
Can you recreate the issues in a chrome based browser? Firefox almost works, but has a nasty habit of popping up a "resubmit information" dialog, which if you cancel, the browser works great, if you accept, it causes all sorts of issues.

Verify the disk type defined in the xml is correct, I seem to remember someone saying it reverted to raw instead of qcow or something like that.

This exactly.

Unraid assumes any multi-drive pool is redundant, since that's the default setting. It's a known issue.

Not recommended, be sure you keep good backups.
See the RAID section of this article, and many others.
https://itsfoss.com/btrfs/

Try setting the share to cache:yes, then run the mover. If you enable mover logging before you run it, you can see any error messages in the logs. If you can't figure it out from there, attach diagnostics to your next post and someone can take a look.

Looks perfect to me.
 
I'd add another step, after everything is complete do a non-correcting parity check, and be sure to keep an eye on the SMART status for all the drives through the whole procedure.

ddrescue appears to do the same thing as safecopy, and it's already available for Unraid in nerdtools.

Expedite replacement, don't bother with extensive testing of the new incoming drive, the rebuild process followed by a non-correcting parity check and long smart test will be a trial by fire for the new drive.
Might be a good idea to order another replacement to have on hand, I personally keep a tested drive same size as parity in a box as an on deck option.
Good reason to consider keeping a tested cold spare to limit time at risk.

Are you sure your phone didn't get connected to a guest network?

Try setting the primary vdisk bus to SATA instead of virtio.

The empty filesystem still has ones and zeroes accounted for in parity, so to remove the disk you will need to rebuild parity after doing the new config without the disk. Do NOT check the "parity is already valid" box, because it isn't. Parity doesn't "do" files, it does the entire drive, which includes the filesystem. Think of the filesystem as the filing cabinet with drawers and blank labels for holding files, it's part of the parity emulation even if there are no files recorded there. That 7GB is the organizational structure needed to keep track of potential files.

Check "parity is already valid" near the array start button, and nothing should be overwritten. New config never overwrites data drive slots, only parity, and if you check the parity valid box, it won't even overwrite parity.

Try reducing the cores and RAM assigned to the VM. Remember, all the resources assigned to the VM are off limits to the host that is emulating the motherboard and I/O. Slow motherboard with lots of RAM and CPU = poor performance.

Dashboard includes cpu time spent waiting for i/o, and since preclear is waiting for the disk i/o 100% of the time it's running...

Slave, note the IP address in the device field, set it to match the fixed IP of your master Unraid.

Master, nothing special, as long as the apcupsd is up and running it defaults to broadcasting as master on port 3551

 
Be sure the network path between the two boxes is powered during an outage, otherwise the slave box will never shut down. I recommend starting shutdown on the slave box almost immediately, so you can be sure it's down cleanly before the master box even starts to shut down. If you have VM's on the two boxes, install the apcupsd program on them as well, use the same slave settings, and start the shutdown first on them. Depending on load, capacity, and desired stress on batteries I recommend starting shutdown on VM's at the 60 second mark, the slave unraid box at 180 seconds, and the master at maximum 300 seconds. That way everything has time for a clean orderly shutdown without distressing the batteries by discharging below 50% or so. Once the heavy draws are shut down, you can leave the UPS running for a little while to keep the network alive.
 
Your situation may differ slightly, but the basic outline will probably be the same.

Extensively discussed in the support thread. Quick fix is delete nginx.conf ssl.conf and replace them with the corresponding .sample files.