JonathanM

Not sure what you are saying here. Parity as implemented in Unraid only recreates a missing or failed disk, it doesn't back up anything. Important data must exist in multiple physical locations and not be effected by issues with a single system. True backups are some form of Parity is much less important than real backups, and most of the time money spent on a second parity drive would be much better allocated to a real backup.

Not sure who you are talking to when you say "you guys". I personally have no access to Limetech company records. @jonp or @SpencerJ should be able to help you, but it would probably be quicker to email them at the support address, they don't always keep close tabs on the forums.

Are you positive your CPU is 32bit only? Have you looked up the specs?

No backup of the stick from any point in the past? How about emails from limetech? They would send the key file to your email when you purchased it. If you exhaust your local backup and email archives, send an email to support, I'd list at the minimum all your current keys that you do have, the emails used to register them, and the approximate date you purchased the license in question. If you don't provide them with a way to differentiate what is in use and which key is lost, there is a possibility one of your live licenses could get blacklisted. Once you recover a copy of the .key file, it's trivial to attach it to a new GUID, that can happen automatically with the help of a wizard. So if you do happen to find the key in your archives, just set up a new USB stick, put the key file in the config folder, and boot it up.

Try removing external access to the webui. While it should be ok in theory, it's not a validated configuration, for now all webui access should be secured by VPN and not exposed.

If your CPU truly does not support 64 bit, then don't bother trying to update Unraid until you change to a processor that does work with 64 bit. Unraid 6.x is 64 bit only.

Sure! The only thing I would suggest is possibly sourcing a new USB stick as well, which complicates matters slightly. What is your current Unraid usb drive? The *.key file is linked to the physical stick GUID, and as long as you keep a copy of that file, you are fine. You can use that file to license a new USB stick, which blacklists the old stick, you can do a license transfer automatically as long as it's been more than a year since the last automatic transfer.

I'm unclear. Are you saying the disks are exactly the same as they were right before the flash drive broke or not? If the assignments are exactly the same, then check parity is valid. If not, you will have to rebuild parity from scratch, which is what the warning is saying. Unraid has no way of knowing whether the assignments are correct, so by default it will rebuild parity, overwriting that drive. If you tell it, yes, I assigned everything the way it was, then it will assume parity is correct and simply check it instead of overwriting it. If you want to move drives around to use the parity slot instead of parity2 and change data slot numbers so disk2 is no longer empty you could that now, however parity would no longer be valid and need to be created from scratch. Only drives assigned to parity slots are overwritten though, your data would still be intact.

Nothing happens with parity, besides that it is updated to reflect the new bits. Parity doesn't store files. It has no concept of file systems or anything. It simply holds the answer to the question, is the specific bit on the missing drive supposed to be a 1 or a 0. Parity will happily emulate a corrupt file system, it will follow along when you reformat to a different file system, encrypted, whatever.

That's probably best, depending on what procedure you are talking about. Single cache has the option of XFS, multiple drive pools must be BTRFS, which requires formatting if you are XFS currently. If you insist on doing the drive failure thing, I'd make sure all your data was backed up before playing around to see if you could get it to work.

Tools, New Config, preserve all, apply, Main tab, rearrange to proper positions. preserving assignments is a convenience thing, it just pre-populates the slots so it's less work to assign them if they are mostly correct already.

Sounds like your router assigned some other device with the static IP you set for Unraid. Can you log in to your router and ensure your Unraid's IP is reserved there so no other device gets it?

@Squid, @johnnie.black, I think he's complaining about the used space calculation in windows vs. the size used in Unraid. Which is probably a smb allocation size thing.

User scripts, set cron for desired times virsh start <VM Name> virsh shutdown <VM Name>

You can toss in any old USB stick (not your unraid boot drive) as Disk1 and assign all your SSD's to the cache pool or UD.

There is no requirement to pay for a license, all the features of pro are free to use. If clicking on the "don't show for 1 week" is not acceptable to you, yes, you need to pay to remove the popup. https://shinobi.video/pro It's set up this way because many businesses have this hang up about using open source software and donating voluntarily, but they will happily pay a license fee for a product they like. The model shinobi is using allows them to get licensing fees from businesses while still offering the same features for free if you wish. tldr; It's just legal licensing to allow some businesses to use the software, you don't have to pay if you don't want to.

Try using only alpha numeric for your password.

Without logs or diagnostics we are shooting in the dark, but first thing to check is your path mapping. Make sure QB is saving files to the folder listed on the container side the the mapping, and the host side of the mapping is set to a spot on your array with enough space and correct permissions.

If you follow the methods as written, parity stays in sync the entire time. Parity doesn't have any concept of files or file systems, encrypted or not. It only recreates bit for bit a missing drive slot by completing an equation.

Try safe mode.

It would appear the qm command is specific to proxmox, not a generic QEMU-KVM command.

In that case, steps 3,4,5 would be the quickest way to migrate.

Well, to be blunt, if you try to 1D10T proof everything, you will lose functionality, performance, and waste developer time that could be better spent elsewhere. I suppose the best way to handle your specific issue is a warning message when you start the array, similar to the question the ticket counter agent asks when you present your baggage, has anyone tampered with your bags without your knowledge?

Edit the apcupsd configuration file on the windows box UPSTYPE net DEVICE <unraidip>:3551

That's correct. A correcting parity check would have updated parity to reflect what was now on the disk instead of what was there before, so that parity would once again be useable to recover from a disk failure. All original content would be gone, just like you intended by erasing the disk. If you didn't want the data erased, why would you format the disk, inside or outside of unraid? Your scenario of pulling a data drive to temporarily use it for something else doesn't make sense.