JonathanM

See Q4: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

See if this helps.

Would you like to share the solution to possibly help others?

Liquid cooling is great for desktop gaming machines that are never left running unattended. Running without supervision there is too much risk for major part damage if something fails and isn't caught immediately. Air cooled massive pieces of copper and aluminum heat up relatively slowly when a fan fails, and many times can run with just convection and case air replacement from other fans for an extended period of time, plenty of time to notify you that something is wrong before major damage happens. When a water loop loses circulation temperatures can skyrocket in seconds, not to mention what happens if the liquid is no longer contained. Set it and forget it systems need passive cooling whenever possible, and redundant airflow options where necessary. Consumer grade liquid cooling is best left for eye candy gaming machines.

Reverse that, or at least combine them. My advice (assuming you have an empty hardware spot for another disk) is to buy the largest drive that makes sense to you financially, then... 1. Do a non-correcting parity check. Zero errors, if not find out what's wrong before proceeding. 2. Remove the parity drive and replace it with the new large drive. Build parity. 3. Repeat step 1. 4. Install old parity disk as a data disk, let Unraid clear it then format as XFS 5. Repeat step 1. 6. Copy the entire content of largest remaining ReiserFS data disk to newly formatted XFS disk. Verify copy is accurate by whatever means makes you comfortable. 7. Format source drive from previous step to XFS. 8. Repeat steps 6 and 7 until all disks are XFS. The reason I recommend copying instead of moving... It's MUCH faster. Moving from a ReiserFS can be painfully slow, where a copy runs as fast as possible. Deleting files and emptying a ReiserFS drive takes eons compared to simply formatting it to XFS. It's safer. You can verify the copy was successful before formatting the source drive. There is a whole sticky thread dedicated to transitioning from one filesystem to another, I've summarized my favorite method here.

There would be notifications on all the configured places. Hopefully you have email notifications set up. All disks in the parity array are treated equally when it comes to write failure.

Parity is there for a measure of high availability, where if a drive won't accept a write request without error it allows you to continue working as normal until you can solve the issue vs. requiring a restore from backups which can take some time. Running with no parity will speed up writes, reads will remain the same, as parity isn't involved in read operations under normal circumstances. The user share file system also adds some overall performance penalties, to get max speed you would need to use disk shares only and turn off the user share system.

The presence of an aspeed chip leads me to believe the board has some form of IPMI. If that's the case, did you assign it a fixed IP? If not, do you see the IPMI interface getting an IP from your router?

The video tutorial you linked has it correct.

No, click on the word diagnostics and see what is needed.

Your network bridge entry is wrong.

NO!

Some drive models require transplanting parts from the dead board to the donor board, if you are attempting this recovery yourself be sure to get all the relevant info specific to your particular drives.

Try deleting the entire item and creating a new port config.

Binhex has a FAQ that covers adding the required settings to his VPN containers that add exceptions to the firewall rules for input and output ports.

If you left ANY of the leads from the old PSU connected to the drives and connected the new PSU to them, it likely burnt out the circuit boards on the drives. There are companies online that can help with board replacement, it's typically much cheaper than full drive recovery.

Those 2 paths are the same. You will lose data. Please read all of this thread.

From the rc4 release notes.

Please keep in mind that parity protection relies on ALL remaining data disks to reconstruct a failed drive. So, if your shiny new 18TB drive fails, you will be relying on those old drives to be read perfectly across their entire capacity to reconstruct a replacement drive. If one of those old drives happens to have a read error on any sector, not just areas currently used for data, the rebuild will have errors. You must not allow any drives that aren't perfect to participate in the parity array. Make sure you run a non-correcting parity check after all the drives are added, zero errors is the only acceptable result. It wouldn't hurt to do a long smart check on all the drives as well.

cifs / smb is typically faster than 9p.

Only the part of the container that has a mapping is elsewhere. Understanding the difference between the container's own filesystem, the host filesystem, and how the two interact with mapping is one of the core principles that you need to get familiar with when working with docker containers.

Another common mistake is running the RAM at too high a speed for the CPU / motherboard. The RAM may well be rated to handle it, but the CPU / board can't, and the BIOS defaults to what is basically an overclock.

I prefer the light theme, as they say, opinions vary. Not that I have any say in the matter, but maybe modify this request to something like, I would like a first setup wizard screen in more neutral tones which asked me what my GUI preference is. The way you asked is rather offputting, especially to those who may prefer a light theme for some things. BTW, I have 4 Unraid servers, 2 at one address are light, 2 at a different address are dark. I use that as a VERY quick way to know which physical location I am dealing with.

Since Unraid was running with the missing disk, any writes to that slot updated parity, so the content on the physical disk is no longer in sync with what is emulated. You have 2 options, either throw away any changes to that slot, and rebuild parity from the missing disk, or update the physical disk to match what is emulated by rebuilding the disk. Either choice results in a lengthy rebuild process, your choice whether you want to throw away the data that was written to the emulated copy and revert to an unknown state on the disconnected drive. If the emulated drive is mounted and looks good, it's usually a better choice to rebuild the drive instead of rebuilding parity. All this assumes your drives are all perfectly healthy with solid connections, any failures while in this state will likely cause lost data.