JonathanM

Pick one or the other. Using both on the same share is asking for trouble.

It can be, since if there is minimal but real damage it may only effect certain things under certain conditions.

The issue seems to be with Unraid still thinking the disk has a valid filesystem, if you stop the array and start it again so the disk shows unmountable, the write speed will increase dramatically. The only issue there is that the script won't work on an unmountable drive, so you must use the manual command line. If you mess up the command line, you can permanently erase a drive you didn't want to. If you are careful and match the md? correctly you will be ok.

Because it's too much work to implement securely?😀

The relatively low thermal mass of the water block can allow rapid temperature spikes if the fluid stops moving or is gone. Processors do attempt to save themselves from overheating, but the engineers assume a certain amount of mass is going to be available even without airflow, so the lack of mass can allow damaging heat in a matter of seconds. Leaks can be very bad as well, even if the fluid is clean, the boards have dust and particles that will mix with the fluid and cause corrosion, a slow undetected leak is the worst as it seeps into cracks and crevices causing voltage to go where it's not supposed to. Worst case would be a slow leak above a bottom mounted PSU, you could end up with mains voltage going to all your sensitive parts at once, blowing out circuit boards on drives. Granted, that sort of failure is very rare, probably because most water coolers are in gaming rigs for show, and any leaks or failures are caught relatively quickly.

Memtest?

No PCIE slots?

Windows update will fill that space rather quickly. If you can't give the VM more space, maybe try using one of the "Lite" windows installs with all the extra junk stripped out.

If possible replace the liquid cooling with standard heatsinks and fans. Liquid cooling is great for gaming machines that are in view constantly while in use, but very bad for unattended servers. The failure modes for liquid cooling can be catastrophic if not caught quickly.

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?

Holy necro batman!

This is the server. The client is packaged with it, and is deployed from the server GUI. I use binhex version extensively, the basic premise is that you log in to the server GUI, add the client description, then download the client from the server's GUI.

What differentiates your template from @binhex's? Whenever there are different templates for the same app, it helps if you tell people why your implementation is different so they can choose wisely.

Not directly. You could create a script that watched for a specific named file in a private share, that user could create said file, the script would reboot the container and delete the file.

?

Sometimes they work, many times they don't. The translation circuits between USB to SATA vary wildly in quality and performance, it's much better to use direct SATA or SAS.

Good news is, GUI boot order is working, sort of, mostly, now. At least it's better than it was when I wrote that.

Unraid doesn't support EXT4 for the array or pools, so that's one choice out of the way. 🙂 Multiple simultaneous writes are better suited for pools, the legacy "Unraid" parity array is more suited to write once read many, like media archives and such. The single or dual dedicated parity disks are the limiting write performance factor in the "Unraid" array. Be very careful using encryption, it limits recovery options if things go wrong, so be extra careful with your backup strategy if you decide to use encryption. Good news though, each disk in the Unraid main array can have a different filesystem, so you can have XFS, encrypted XFS, BTRFS, encrypted BTRFS, ZFS, encrypted ZFS, all protected from single or dual disk failure by 1 or 2 parity drives. Parity in the Unraid main array is file system agnostic, it recreates the entire disk regardless of filesystem. ZFS is only available in 6.12 Pools can be single volume XFS, or RAID BTRFS or ZFS. So, your storage can be tuned to your needs, fast SSD pools for high I/O, and mix/n/match disks in the parity array.

Don't know if it applies to your specific setup, but I've seen anecdotes of needing to keep a VM running to keep the power consumption of a graphics card low. Apparently some cards stay in high power mode until told to simmer down by their drivers, which in Unraid generally means inside the VM if you are using the card for VM's.

Now that pools have ZFS and BTRFS RAID options available, feel free to mention RAID whenever the need arises. 🤣 Unraid is so much more than just the way it handles disks.

The only issue I see with leaving them in the array is if one of them fails, it puts your data at risk, even if they are empty. Personally I'd dev/zero them, and do a new config without them. If your server stays up for months at a time between reboots, they can stay spun down in UD, ready to be put into use at a moments notice (hot spare, sort of)

Try setting the array NOT to autostart. If it works after a hard boot with a manual array start, it's probably a network timing issue.

Starting a parity operation spins up all drives. Spin up events are far and away the highest current draw, but only for a few moments.

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.

Unfortunately Marvell has a bad reputation with linux compatibility. They work for some people, but other systems randomly drop drives.