JonathanM

That presupposes full root access to the server, not just

Before the great forum update a little while ago, it was possible to manually add spoiler tags, and they worked fine. I can't get it to work for me anymore even though the posts I used them in previously still work properly. Originally, I replied stating you could use the spoiler tag, and tried to post it collapsed. When it didn't work properly, I deleted it, since I couldn't add positively to the discussion.

UPS

Easiest would probably be to use tools inside windows to do a typical backup and restore. https://www.windowscentral.com/how-make-full-backup-windows-10

The mover tuning plugin can be set to do what you ask. Many people are using lower grade SSD drives that wear out quickly when kept full and constantly active.

Yep, since each disk has an independent file system, they don't even have to be the same format, it follows that each file must reside wholly on an individual disk, no splitting files across volumes.

It's been deprecated. You will need to update to the 6.9 rc to use the replacement.

/data <-> /mnt/cache/Downloads -> deluge, sab, and sonarr is not the same as /downloads <->/mnt/cache/Downloads -> radarr data != downloads, those are currently different. They must be the same. Nothing with regards to container path mapping has changed, it's been this way since docker was added to Unraid.

Both sides of the mappings must match, not just the host side.

Shares are simply root folders on the disks. To "move" files from one share to another simply means renaming the root folder and other folders in the path, they are still on the same physical disks.

Why another motherboard? Are you out of PCIe slots?

If by combine you mean use the disks in another NAS as array drives in Unraid, then no. You should be able to mount the NAS as an Unassigned Device to access files on it. To attach an external box with disks assigned as array devices you need SAS connections, typically you would have a LSI HBA like https://www.broadcom.com/products/storage/host-bus-adapters/sas-9300-8e in the Unraid motherboard with cables to a SAS disk enclosure, possibly with an expander.

Yep, That simple. Just make sure you ONLY use /mnt/user root paths. Don't stray into /mnt/cache or /mnt/disks, you can easily lose data if you don't know how those direct disk paths interact with /mnt/user.

No. Only if you removed the network type from the container and added --net=container.... If you are still using bridge or host for the container and specifying privoxy inside the app you don't need to do anything else.

Just to be clear, you did this through the apps tab, by clicking on Previous Apps on the menu to the left?

Cool. I added a post and recommended my own post to draw attention to it in @SpaceInvaderOne tutorial thread.

https://forums.unraid.net/topic/75539-support-binhex-qbittorrentvpn/?do=findComment&comment=951967 If you are using binhex's containers, or any derived directly from his work, you will need to follow this post.

I'm assuming this is in addition to mapping those ports.

Ouch. I certainly hope your efforts here weren't the tipping point.

The way you worded that concerns me that you are expecting parity to be able to recover individual files. Unraid's parity doesn't do that, it doesn't contain any backup files. https://wiki.unraid.net/Parity

Option 4. Use the new disk as a periodic full backup of your data. RAID, Unraid, etc, are for high availability, where you still have access to your data uninterrupted while replacing a failed drive. That is the ONLY data protection they offer in this context. Drive failure is only one of many ways to lose data. Accidental or malicious deletion, user error, file system corruption, etc, are not protected against, only backup can help there. So, to improve your data resiliency, you need a full versioned backup in a different physical location.

https://forums.unraid.net/topic/88086-support-bitwardenrs-bitwarden_rs/?do=findComment&comment=948861

Already requested, with discussion.

Right there with you. I resigned myself to working around the behaviour by setting up quick connect profiles with 5900, 5901, 5902, 5903, etc. It could take 2 or 3 tries to get the machine I want, but I eventually get there. The overarching issue of GUI changes killing XML customizations is a VERY longstanding issue, apparently the intent was to wrap all possible changes into the GUI and only the most obscure changes should need to be made manually. But, as you point out, there are some really common tweaks that aren't in the GUI, like a working boot order changer, vnc settings, etc, etc. Honestly I think the answer is to scrap the VM gui entirely and plug in an adaptation of virt-manager.

Check the free space on all the array drives before you start the transfer, while you are doing the transfer, and after you get the error. Also, if you have a cache pool with multiple devices, there are situations where the drives get fully allocated even though the GUI shows free space. It's a BTRFS file system bug, not something Unraid can fix. Attach the diagnostics zip file to your next post if you want assistance figuring out if that could be the issue.