JonathanM

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.

Just paste the image inline, links to foreign sites are frowned on.

This, theoretically. But you can new config, keep all, and just change what needs to be changed.

No.
You can use the Dynamix File Manager to move data to another drive.

The manual method of setting up a new flash drive is almost what you ended up doing. Extract the contents of the os zip file to the flash, run the make bootable script that matches the machine you are setting up the flash with, and boot. To make it your custom install instead of a new one, the config folder is all that's necessary.
 
I'm unclear where this
file came from, but it certainly didn't contain what you needed.

Click on the container in the Unraid GUI, you should get a popup like this.

Click on the ? Support link, it will take to the correct place to get information and ask questions about that specific container.
 
The general support (where you posted this question) is for the Unraid system itself, containers and plugins all have their own threads with information.

The /config folder in the root of the flash holds all your customization.

When you assign a specific IP address to a container, there is no mapping needed or applied. All ports are directly exposed on that IP.
 
The bridge setting shares the servers IP, so only mapped ports are exposed, and those can be redirected as needed to deconflict multiple containers sharing the same IP.
 
When you assign a unique IP to a container any port settings are managed in the application itself. Unraid's UI will still show the port settings, but they do nothing.

Temporarily add it as a second disk to a working VM.

Remember, Unraid only "fails" a disk when a write error occurs. Sometimes that can happen when a read error happens, and Unraid automatically tries to write the emulated data that should be there, and the write fails, so yes, in that case the dropped drive data is fine. However, if it happens with a write command NOT the result of a failed read, that means the physical drive is guaranteed to be different than what is emulated in the array. If you throw away the emulated data in favor of what is on the physical drive, you lose the latest writes.
 
So, your choice is either to rebuild the data drive, or rebuild the parity drive. Either takes about the same amount of time, but rebuilding the data drive ensures that the latest writes are preserved.

Sounds like windows is using saved credentials.
 
Try removing the server name or IP from windows credentials and try again, also make sure your windows username and password isn't an allowed user for the share.

First question, are your binaries native linux?
Second, where are you keeping them? The flash drive won't work, you must run them from another file system, either an array drive, a pool, or RAM. If you wish, you can keep the original binary on the flash drive, then make a copy into RAM, set them as executable, and run them from there.

Many instances I see are overclocked systems. I'm not aware of anything special with Unraid.

Dashboard includes IOWait

A properly precleared drive that hasn't had any bits changed is universal to any Unraid install.

That's an issue. I don't know if it's THE issue, but like I said, you need to copy the contents of the zip file, then run the make bootable. The make bootable script should be in the root of the flash drive along with the efi and all the other folders and files.

Tools, new config, keep all, go to main page and remove the missing drives. Start the array and allow parity to be recalculated.

Try removing the mover tuning plugin. If the problem persists without the plugin installed, post back to this thread. If the problem is resolved, post in the support thread for the mover tuning plugin.

This statement feels wrong, but it may just be terminology. File system corruption is dealt with by doing a file system check, a disabled drive is dealt with by rebuilding it, preferably to a different replacement drive so the original drive is still available if more recovery options are needed.
 
If a drive slot displays unmountable, a rebuild won't fix that. The parity equation emulates the entire file system, if there is corruption that is also emulated. It doesn't know about files. A drive that failed a write is disabled with a red x, and parity takes over emulating that drive slot. If parity was valid when the write failed, the emulated drive will be identical and all files will be available, that is what will be rebuilt to a new (or the same) drive when you rebuild. If the emulated drive is unmountable, the rebuild will also be unmountable.
 
Hopefully you already understood all this and just used the wrong words.

If you do the upgrade in maintenance mode, so the data drives are not mounted, the old parity drive would stay valid.