JonathanM

What ports do you have opened to the server on your router?

What is your seniority in the project? If you leave, what will happen to the tech? My normal response to someone wanting to use Unraid in a business setting is to discourage it unless the person doing the asking, building, and maintaining is a principal in the company, better yet an owner, preferably a single owner, not a partnership. Unraid is great if you are willing to maintain and babysit, not so much if it's going to be set in place and ignored for years. If your supervisor is fine with you being the ONLY person responsible, fine, I guess. I just don't want to put Unraid in the position of being the bad guy when you move on to another project.

Need more back story. Hardware failure? User error? Malicious actor?

Some motherboards work with the cpu temp plugin, but it's not universal.

I don't believe there is a way to pause the parity copy portion of the parity swap procedure. Any way you can temporarily cool the server's environment to help it limp along for the duration?

Long years of experience and good memory.

If you edit the container and switch to advanced view you can add notes in the additional requirements field that nobody uses anyway.

I don't think it should be, but sometimes memory fragmentation comes into play, where the total amount free is fine, but the largest contiguous block of memory is too small. Rebooting is the only thing I know to do in that situation.

The community can help you troubleshoot, but you have to be patient and provide the needed information so we can help. Being combative to the volunteer community isn't nice, we are all just users trying to help each other.

Backup backup backup. There are more stringent security things you can put in place for WORM data, here is an old thread (some things no longer apply) that discusses some of the strategies. https://forums.unraid.net/topic/58374-secure-writing-strategy-for-unraid-server-using-write-once-read-many-mode/

How much RAM did you leave open for Unraid? Your sig says you have 32GB RAM, perhaps you need to lower your VM's allocation. Oftentimes the best performance is obtained by reserving only the minimum necessary for the VM to function, and allow Unraid to use the majority of the RAM for I/O caching. Try running the VM with 4 or 8GB and see how it performs.

The empty filesystem still has ones and zeroes accounted for in parity, so to remove the disk you will need to rebuild parity after doing the new config without the disk. Do NOT check the "parity is already valid" box, because it isn't. Parity doesn't "do" files, it does the entire drive, which includes the filesystem. Think of the filesystem as the filing cabinet with drawers and blank labels for holding files, it's part of the parity emulation even if there are no files recorded there. That 7GB is the organizational structure needed to keep track of potential files.

If you would have posted the entire width, we would have better answers, but yes, if that line shows a mounted filesystem on the right side of that screen, any data on that slot will be lost if you do a new config instead of rebuilding on a physical drive.

Just add the disks as scan locations, don't scan the entire /mnt tree.

inner (FTFY)

I'm just concerned there will be a bunch of very confused people not able to log in.

Is this multi language ready? I couldn't find this blog post in the foreign section.

If you run the air conditioning most of the year, you can almost double the savings of any power reduction, because you aren't paying to remove the heat. If you run the furnace in the house more often, then the savings due to power reduction are almost gone, because the electricity to run any computer is converted pretty much entirely to heat. Hot climate = more savings by reducing power. Cold climate = don't bother.

Yes or no, depending. Cache yes, moves data from cache pool to array, as long as the data is not in use or open. Cache no, mover does nothing. The help text on the share page should help clarify this. Most secure would be to upgrade parity drives one at a time, doing parity checks after each upgrade. Then use the better of the two old parity drives to upgrade disk1, once again doing a parity check after the upgrade is complete. COPY the data from disk2 to the new disk1. Upgrade disk2 to 16TB, once again parity check after the operation is complete. Format disk2 to clear it out, change desired format type, format it, then change it back, format again. Takes a few minutes each, not long at all. COPY the contents of 3,4 and 5 to disk2. Set a new config, preserve all, then set 3,4 and 5 to none, build parity again, check parity again. If you follow this exactly, you will end up with all your data where you requested, and none of your original data drives will be overwritten, they can stay intact as backups. For ZFS questions, my best answer is wait until it's been live for a few months, ZFS itself is fine, but the Unraid integration could have teething problems, best to wait and let the bold take the risks.

Keep in mind that the disk slot was still available for writing because of the parity emulation, so before you do the new config make sure all the data on that disk slot is backed up elsewhere. It's entirely possible that between the time you cleaned out the emulated disk and now that Unraid wrote data there, especially because it had more free space than any other drive.

Check "parity is already valid" near the array start button, and nothing should be overwritten. New config never overwrites data drive slots, only parity, and if you check the parity valid box, it won't even overwrite parity.

Small drives are more apt to concentrate heat, causing a possible shortening of lifetime. Physically larger drives are preferred, metal casings help as well with heat dissipation. I personally would never leave my Unraid licensed drive on the outside of the case, if the motherboard doesn't have an internal USB port already, I use a 10pin USB adapter on one of the motherboard internal USB headers and mount the drive inside that way.

Recreate the flash drive like you did originally, copy the config folder back to the flash from your backup, and see if it boots.

Download location mapping in docker run compared to download location set in deluge would probably tell the tale.

If you are doing it correctly, you never NEED to back it up, because all your customization and unique files live outside the image. Creating a new image and loading your existing configs is quick and easy.