JonathanM

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.

This should be posted in the support thread for the specific container you are using, but it appears that you don't have a container path for /downloads set. Probably need to duplicate the path entry (both host and container sides) from your sonarr to your bazarr config.
 
If that doesn't fix it, post in the support thread for that specific container.

Pretty sure you can preclear without starting the array, which means an expired trial should work just fine.

No.

Assuming you are talking about a krusader docker container running on the Unraid in question, that's to be expected. Containers only have access to file paths specifically mapped to them, all other paths are inside the docker image.
 
Easiest solution is to shut down Unraid, put the boot stick in another computer and do the copying there.

You must change the listening port in the application itself, not in the container config.

On that main GUI page click on each blue disk link text and set the disk format type.
 
BTW, formatting in UD before adding them to the array is not recommended, much better to allow them to be formatted after they are assigned to the array.