JonathanM

If the stock scheduling doesn't give you the flexibility you need, maybe look into the tuning plugin?
 

Dynamix File Manager

There may be other ways, but the quickest way I know is delete and recreate the docker.img file.
 
Be sure to create your desired networks BEFORE going to previous apps and selecting everything you want to reinstall. It should only take a few minutes, and everything will be back the way it was.

I don't know if the time being wrong will give that error, but try setting the BIOS time to GMT.
 
You should be able to save the diagnostics zip file to the flash, shut down the machine, then attach the zip file to your next post here.

https://docs.unraid.net/unraid-os/manual/upgrade-instructions/#manual-upgrade-or-downgrade

At this point you may as well format the drive and write your backup to it, run the make bootable, and see what happens.
 
If it gives you errors while formatting or writing your backup to it, proceed with a new drive.

Set up a new VM, get it running to your satisfaction, then add the corrupt vdisk as a second disk to that new VM.

It is an issue, usage doesn't matter, any RAM allocated is denied to the host completely. Try setting the windows to 8GB and the linux to 4GB and see how they perform.

Deleting files doesn't clear the drive. The entire drive must have zeroes written to it, so when it is removed the parity is still valid. Preclear DOES write all zeroes, but you can't preclear a drive while it's in the array. There is a script that does clear the drive while it's in the array so you can remove it without recalculating parity, but the script doesn't work well for many people, it's very slow.
 
I think you need to stop the array, unassign the parity drive, start the array so it forgets it, stop the array, assign the parity drive so it will recalculate from scratch.
 
A clear drive in Unraid terms is all zeroes. A drive with all the files deleted, or formatted, even if it shows an empty filesystem still has a whole mess of ones and zeroes on it, some from the deleted files, some from the filesystem itself.

The main parity array doesn't stripe data, so writes are limited to single drive speed. Turbo write only affects parity involved operations, so without parity turbo write doesn't change anything.
 
It's possible you may get better speeds if you write directly to the disk shares instead of user shares, bypassing the fuse system, also you could manually target writes to multiple disks simultaneously.

Tools, new config. Just make sure you don't accidentally assign any drives to the two parity slots.

Have you worked through the steps here?
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#comment-819173
 

Currently not possible AFAIK.

If the containers don't have a built in permission fix setting, (some of binhex's do) then the easiest way is to delete the appdata and start over. That will lose all your settings and data however. Otherwise it's probably going to be a tedious process of manually setting the permissions to what is needed, the only way I can think of would be do a second install and see what the permissions were on a running install and emulate them.
 
Each container will be different, so I recommend asking in the support thread for the specific containers you are working on to see if there may be a shortcut to fixing it.

binhex's vpn containers are locked down tight, all IP's that need to access the GUI must be whitelisted in the container template.
See Q30
https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
Probably a good idea to read the whole thing, there's a lot of good info about using his containers.
 
p.s. Each container has it's own support thread, to keep all the information in one place. You are meant to post in the specific thread for container support, not start a new thread. For Unraid OS specific questions, you ARE meant to start your own thread in the general support area.

Temporarily obtain 2 surge protecter power strips with switches. We need to turn off the power without breaking the ground circuit, so no yanking plugs out of the socket.
 
Obviously starting with both servers safely shut down, along with everything else you plan to plug into the UPS.
 
Plug all the power cords that will go to the UPS into surge protector 1. Plug the UPS input into surge protector 2
 
Make a (hopefully measured) educated guess on max power draw of everything plugged into surge protector 1. Bonus points if you have an accurate wattmeter to feed surge protector 1.
 
Leave the USB connection from the UPS going to Unraid 1. This is why you need surge protectors instead of yanking the plug. Very bad things can happen if the UPS ground isn't tied back to the PC when it loses power.
 
Fire up the UPS with nothing but the USB lead and power input connected.
 
Boot up all the equipment on surge protector 1. Start a non-correcting parity check on both Unraid servers, and have everything started and loaded like it would in a worst case unattended power outage. Read the power draw if you have meter of some sort.
 
Connect a similar draw non critical load to the output of the UPS. Good candidates are halogen work lights, incandescent lights if you have any around any more, space heaters on low, use your imagination to find enough load.
 
Now you are ready to start the actual testing portion. This should be done with observation only, resist the urge to manually intervene. You should have a way to watch the dashboard of both Unraids.
 
Turn off the surge protector feeding the UPS to start the "power failure".
 
Observe the loads connected to the UPS, look for flickering lights or fan speed variations on the heater, whatever you have connected.
 
Remember to turn off any tech not connected to UPS, to accurately simulate a power outage. Optionally for a more thorough test disconnect your outbound internet if you can do so safely, unless you are using cellular WAN, as a real power outage may drop the WAN outside of your control. Watch to see if you get notifications on the Unraid dashboards of a power failure. If everything is working to plan, Unraid 2 should start the shutdown process cleanly after 5 minutes. When it shuts down, you can adjust the load on the UPS to match, maybe turn off one of the lights connected. After the 10 minutes has elapsed, hopefully Unraid 1 starts a clean shutdown. When it's done, you can adjust the load on the UPS if you want. At this point if the UPS is still running the dummy loads, you can call it a success, depending on what you observed.
 
Other considerations.
 
After draining the batteries on a UPS, make sure you account for recharge time before depending on it for more backup, since a typical recharge rate is 10 to 20 times slower. If the UPS was running on battery for 15 minutes, allow at least 3 hours recharge time.
 
SLA UPS batteries, the most common type, get touchy about being drained more than 50%. Their capacity and lifetime is reduced the deeper the discharge, so try to stay in the top of the curve. If you are discharging too deeply, reduce the time on battery parameter.
 
Personally my secondary loads like client pc's, VM's, etc are all set to shut down after a minute or two of power outage. Keep in mind you can install apcupsd clients on any VM's hosted on Unraid to get them cleanly shut down prior to the main timeouts and reduce the shutdown time.
 
If during the test the batteries are drained before the timed shutdown is done, you need to upsize the UPS, or restructure to multiple UPS since you are aiming for less than 50% drain, and you can't shorten the delay meaningfully.
 
If the communication path between devices is broken or interrupted, the shutdown signal will be lost. Make sure all network infrastructure can outlast the full shutdown period.
 
I recommend NOT trying to have things automatically recover after a power loss event. Much better to manage the recovery hands on, watching and controlling, especially checking UPS battery condition to ensure enough capacity to handle another shutdown if power goes out again during the boot up process.

Rename the EFI- folder to just EFI

As a general thing, the best practice is to not mess with it, just leave the full drives full, and let all new writes go to the new drives. The first bit of the drive is the fastest, the last bit the slowest. Just make sure your split levels and minimum free space is set correctly.
 
If you really want to move a specific share from one drive to another, the best way would be the Dynamix File Manager plugin.

When you enabled the docker service, an empty image was created to hold the container executables. Kind of a preallocation.

You can't add it to the array without formatting it, but you probably can mount it using Unassigned Devices to read it so you can copy it to a different array disk.

Look in the config folder on the flash drive for multiple files named *.key

Depends on the USB implementation of both the motherboard and the drive.
 
Some seem to be stable, others flake out and disconnect on a whim.
 
No way I know of to tell the difference without trying it.
 
It's not recommended simply because it's unstable more often than not, and there are other issues with USB in the array itself, which you aren't doing, so if it works for you in this specific instance, great.
 
I wouldn't expect a whole lot of speed though.

No. Each disk in the parity array is an independent filesystem, the user shares are a merged directory tree across same named root folders on all participating disks.
 
Technically the answer to your thread title is yes, you can create vdisk's larger than the available space because they are created sparse, and only occupy the space actually written inside the image. However, as you found out, when the containing disk runs out of space, the vdisk doesn't have anywhere to put the data, so the virtual filesystem doesn't work correctly.
 
Instead of using the parity array, you can assign multiple disks to a pool, which can use either BTRFS or ZFS RAID levels to create a single filesystem spanning multiple physical disks.

If you really want to, you can delete the trial key and put your old license key file on the new stick and do the automated transfer, but that blacklists the old stick, limiting your options, and you only get 1 transfer per year through the automated system, otherwise you must contact support to get things sorted.
 
Much easier to just use the old stick with a valid license already.