JonathanM

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.

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.

Try reducing the cores and RAM assigned to the VM. Remember, all the resources assigned to the VM are off limits to the host that is emulating the motherboard and I/O. Slow motherboard with lots of RAM and CPU = poor performance.

Dashboard includes cpu time spent waiting for i/o, and since preclear is waiting for the disk i/o 100% of the time it's running...

Slave, note the IP address in the device field, set it to match the fixed IP of your master Unraid.

Master, nothing special, as long as the apcupsd is up and running it defaults to broadcasting as master on port 3551

 
Be sure the network path between the two boxes is powered during an outage, otherwise the slave box will never shut down. I recommend starting shutdown on the slave box almost immediately, so you can be sure it's down cleanly before the master box even starts to shut down. If you have VM's on the two boxes, install the apcupsd program on them as well, use the same slave settings, and start the shutdown first on them. Depending on load, capacity, and desired stress on batteries I recommend starting shutdown on VM's at the 60 second mark, the slave unraid box at 180 seconds, and the master at maximum 300 seconds. That way everything has time for a clean orderly shutdown without distressing the batteries by discharging below 50% or so. Once the heavy draws are shut down, you can leave the UPS running for a little while to keep the network alive.
 
Your situation may differ slightly, but the basic outline will probably be the same.

Extensively discussed in the support thread. Quick fix is delete nginx.conf ssl.conf and replace them with the corresponding .sample files.

Try reformatting the drive with RUFUS
 

Try reformatting the new USB sticks with RUFUS, then follow the normal install instructions.

Have you tried SeaBIOS instead of OVMF?

Too many different goals have different requirements. No way to generalize except to set an upper limit that is rational for some situations, keeping a minimum free space of at least the size of the largest single file that is currently on the disk or a few multiples of that.
 
You need free space if you need to run file system checks, if you get corruption too little free space can keep the repair from completing.

If you stop VM and Docker services, so the menu items no longer appear in the GUI, you should be able to use Dynamix File Manager to move all the appdata folders onto a single disk. Then set the split level to manual, and it should stay on whichever disk you put it, and you can re-enable the Docker and VM services.

Semantics. The backup put the key file that belongs to the old USB stick onto the new stick, so you must obtain a new key file that matches the new stick. That's done with the replace key procedure.
 
I realize I'm saying the exact same thing that you said, just wording it differently, if I'm not clear reply back and I'll try to explain better.

nomachine

This guy has many videos encompassing pretty much all Unraid can do, have a poke around and see what you see.

What result do you get when you ping your duckdns name?

Can you log in with SSH if you set "Use SSH" to Yes on the Management Access page?

Assuming you have the file manager plugin, click on the "view" icon at the far right of disk1, select all, move, and select disk 2 as the destination.

Thank your lucky stars that you didn't blow up all your drives. Modular cables are not always compatible, EVEN from the same name brand.
 
Unless you know how to operate a volt meter and test the pinouts before powering your drives, NEVER reuse modular cables with the different PSU, just keep them together as a set.

Either
add more RAM
limit the amount of RAM your containers are allowed to use
quit using the containers that use too much RAM
set up a swap file on a pool disk (not officially supported, but has worked for some in the past)
 
Keep in mind that the OS unpacks into, and runs entirely from, a RAM disk, so killing processes that are consuming excessive RAM is the only defense against total crashes. It's also possible that you have something writing to RAM, since all the typical OS locations are in RAM instead of on a hard drive. If a file is being written to a location not mounted to one of your array or pool disks, it's writing to RAM.
 
Without you taking the steps to figure out which container(s) are causing the overflow it's tough to help. The VM reserves as much as it's assigned, and that chunk is untouchable to the OS, so even if the VM has free RAM the OS can't use it. Best to reduce the VM RAM to the smallest possible amount, and let the OS manage the rest.

Perhaps this?
https://www.gbmb.org/tib-to-tb

Update to 6.11.3

Upgrade to 6.11.3

Sure, just use BTRFS

Yes, if you set up a new flash drive with a trial, purchase the license, then copy the entire config folder to the newly licensed flash without the old *.key file.
 
Since you say you are having issues with the flash drive I'm assuming you are working with backup files from the drive, so just make sure you keep the key file with the physical key it was issued to, and overwrite the rest of the config folder's content with the active server config files. Probably should just remove the old dead *.key file from the backup you are working with, and make a separate copy of the newly issued key file and label it to correspond with the new physical USB stick.
 
I'm not sure how clear I was, so if you have questions just ask.
 
P.S. Are you using a USB 2.0 connection to the motherboard? Typically that results in less issues. My favorite USB drives are all metal and relatively large, for good heat dissipation.

USB enclosures sometimes alter ID's in unpredictable ways, for instance yours may be reporting for the first slot that responds, and subsequent drives aren't. Some USB cages are better than others, but all suffer from bandwidth issues for parity.
 
The only external hard drive cages that work comparable to internal SATA connections with Unraid is either ESATA with one port per drive, or SAS which allows multiple drives for a single cable.
 
USB suffers from poor connection stability under heavy load, which can cause Unraid to disable drives somewhat randomly.
 
You should be able to successfully use Unraid with USB connected array drives if you forego parity protection and just use data drives and single volume pools, any attempt to use parity with multiple USB data drives is going to be a frustrating experience compared to HBA sata internal connections.