JonathanM

You MUST copy the file to somewhere other than /boot. Linux permissions aren't honored in any path under /boot because it's FAT32, which doesn't support linux file permissions fully.

Read errors that are successfully calculated from parity and rewritten to the drive in question do not result in failing the drive. However... it's kind of misleading, and at first glance I'm hesitant to trust the result 100%, since the parity was forced to be correct at those addresses that failed the read. That's a whole can of worms that's a little above my pay grade, if @limetech isn't too busy maybe he can pop by and provide some clarity on what happens when a read error occurs during a parity check. My gut says parity is assumed to be correct for those specific sectors, with no way of verifying that unless you have 2 parity drives. That means it's possible for the data to be wrong at those addresses. Not particularly likely, just possible. As far as the drive itself, I'd run the extended smart test and see what results you get.

That will mean rebuilding parity. The two slots are not equivalent. How confident are you in the health of your drives right now?

Unraid NAS is pretty much set and forget, as long as you have notifications set up and keep up with basic maintenance. Containers, not so much. Unless you learn how to do things yourself, either by paying for the education or self learning, you will be paying over and over every time things change and update. I know it seems like a lot to take on, but honestly, much of the satisfaction is learning to handle things on your own, either by watching tutorials or asking good succinct specific questions on the support thread for whichever container you are dealing with. If you pay for someone else to set it up, you will either give up when it updates and stops working, or you will be paying over and over again.

Very occasionally I've seen a network card freak out and lock down the network. Try unplugging the ethernet connection to one of the devices involved in the transfer and see if the network comes back to life. If you can isolate it to the Unraid box, try a different ethernet adapter.

Follow the manual install instructions, you will need a temporary OS running on the server, like a live linux or something. Roughly, format the stick to FAT32, copy the files from the manual download to the stick, run the make bootable script.

Since you say you built it, I'm assuming you are relatively familiar with PC stuff. Take it back to the bare minimum, PSU, motherboard, CPU and heatsink, power button lead. NOTHING else plugged in. No RAM, no cables except power, nothing. See if you get a "RAM missing" code when you trigger power. If so, add 1 stick of RAM and see if the code changes. If so, and you have onboard video, plug the monitor back in and see if it initializes. Keep adding pieces ONE AT A TIME until you get failures again. If you can't get a bare motherboard and cpu to give you a ram missing signal, either the board or cpu is probably fried, but sometimes removing the CPU and reseating can help.

How much free space is showing in the VM? vdisks are sparse by default, so they only show allocated what is actually in use by the VM.

I totally get why you want to approach it that way, but ideally shutdown should be handled ASAP, and housekeeping should be a periodic task that doesn't interfere with shutdown. Many people run Unraid mostly unattended, and automatic shutdowns need to be handled gracefully and with as little delay as possible.

Physical configuration doesn't matter, but slot assignment is how drive order is determined. Slot 5 is not equal to slot 9. Just because you move a whole block of drives, it's still a different order because slot 5 doesn't contain the same bits as it did before you reassigned it.

Diagnostics zip file?

Link?

Which set of instructions are you following?

Not spaceinvaderone, but the clear advantage to using full passthrough vs privoxy is you are assured of all communications going through the tunnel, vs just web traffic.

Try a different USB - SATA adapter. Honestly though, because of how unreliable USB is under load, I wouldn't recommend using parity at all. You would probably be better off keeping the extra drives for manual backups of important data.

Best option could be a second cache pool, available in the 6.9 beta

Looks good so far. With the 2 8TB drives connected and the array stopped, just click Add Pool and go from there.

I don't see the 2ea 8TB drives in the Unassigned section. Are they connected?

https://forums.unraid.net/topic/88456-catastrophic-hard-drive-failure/?do=findComment&comment=833305

Can you post a screenshot of the MAIN GUI with what you have done so far?

Begin by sourcing a quality 4 pin molex to SATA power adapter. Be SURE that the SATA end has crimp connections, no one piece molded where the wires just disappear into black goo, you should be able to see the wires connect to shiny metal in separate slots. Using only that piece plugged into a single hard drive, see if the drive spins up. Don't connect SATA data wire, just give the drive +5, +12 and ground and see which drives spin up. Once you have an update with that test, post back with results.

Start reading here. https://forums.unraid.net/topic/44119-support-binhex-sabnzbdvpn/?do=findComment&comment=481133

Checking to see if the VM is already running before issuing the VM start is NOT what I meant. You need some way of keeping the VM from trying to start automatically, for troubleshooting purposes. Consider the case where starting the VM immediately hangs the host, for whatever reason. You would be stuck in a loop of bouncing the host, and attempting to get access to kill the startup script before it initiates the VM and immediately hangs the host. You need an out of some sort to allow you to stop the auto start process cleanly. That conditional check, where something external is evaluated before starting the VM, is what I was referring to when I said not to blindly start the VM. It could be as simple as a script in the VM itself modifying a file on the host when it shuts down properly to signal it's OK to restart when needed. That way if the VM crashes for whatever reason, it's not blindly restarted.

Copy is always faster than move when going from one parity protected array disk to another. Reason being, when you move, the source disk is asked to delete the file after the copy, which is a write operation to update the table of contents. So you are writing to both the source and destination disks, both of which are updating the parity disk, at different physical addresses, causing a slowdown in general, typically halving performance or worse. It REALLY doesn't help that ReiserFS can take ages to delete files anyway. However... if you copy instead of move, you have to do more due diligence to make sure nothing is added or changed on the source drive between the time you started the copy and finished checking to make sure the copy was done completely. If you are moving files, it's pretty easy to check that the source drive is indeed empty before formatting. So, your choice is speed and being aware of what's being written to the array to the finest detail, or take your time and move things. BTW, copying introduces another quirk that you must be aware of, that is the duplicate files on the disks will temporarily cause the user shares to act strangely if you aren't aware of what's going on. Consider this, file at /mnt/disk1/usershare/text1.txt is copied to /mnt/disk2/usershare/text1.txt and you navigate to /mnt/user/usershare. You will only see the first copy that's physically on disk1, and if you edit it, the changes happen on disk1. If you then delete the file on disk1, your changes will be gone. Also, if you are looking at the file on /mnt/usershare, and delete it while both copies exist, it will appear as though nothing happened, because the file on disk2 will take its place. If all this sounds too complicated to digest, then just continue with your original plan, it will work fine, just slower. If you are willing to disable the docker service, VM service, and force everyone to stay off the server so nothing will get changed while copying is in progress, then copying is the way to go.