trurl

You posted again while I was typing, so hopefully you will reconsider. One of the things that will happen when you transfer the license is blacklisting the original flash.

But the cloned license key won't work on another flash. Not exactly break it. It just wouldn't work on a different flash drive. And to get that other flash drive licensed, you would have to go through the registration process again. This is free, automated and can be done directly in the webUI, at least for one license transfer per year. And the license for the old flash would be blacklisted. So, as you can see, a clone may be a clone in many ways, but if it isn't the same flash drive then it isn't really a clone in an important way.

On the Dashboard, or on the Docker page, simply click on the icon for any of your dockers and you will get a popup for all the things you can do with that docker, including remove it.

If you get a new diagnostic, it should include the latest syslog information (assuming you haven't filled your log space). What it won't include is any syslog from before the latest reboot. Possibly you are referring to an old diagnostics that you got off the flash drive. You can get a new diagnostic For many situations, we don't want or need the separate syslog. Only when the needed syslog information was lost due to reboot do we ask for it, and Syslog Server is the way to get it saved.

Multiple cache pools are planned but not yet available. Personally, I don't think those 1TB HDDs add much to your setup, especially if they are old. If you are already planning to run the 120G SSD Unassigned for dockers/VMs, then the 2x256 SSD cache may be enough for caching user shares after you get the initial data load done.

Diagnostics zip file contains syslog as noted, but it only includes syslog since the last reboot. Since your problems are causing or requiring a reboot, those problems are not in the syslog included in diagnostics. So, the syslog you get like that from the flash drive can also be useful in this situation. You say it is rebooting itself now. Are you sure you don't have a power or cooling problem?

Don't see any other problems. Replace parity

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post so we can get a more complete understanding of your situation. But Definitely replace ASAP A larger parity disk will allow you to use larger data disks in the future.

CPU usually has little or no effect, it is mostly going to be the disks and how they are used. If you have cache, then you can write at whatever speed cache will support, since parity isn't involved. In addition to using cache, another possibility is to simply not have a parity disk. If you to a disk in the parity array, and you have a parity disk, then you will get lower speed than a simple write to a single disk because parity has to be updated. See here:

Looks like your cache drive is corrupt and read-only, as is your docker image on that cache. I think the usual advice is to backup and reformat. See here: https://wiki.unraid.net/index.php/Replace_A_Cache_Drive

Does he have a cache disk or cache pool?

As suspected, you have multiple container mappings for the same host mapping. Each of those container mappings that are in UPPER CASE are also mapped in lower case to the same host path. You really should try to understand docker volume mappings instead of blindly following instructions. If all you wanted to accomplish was editing go, you could have done that directly with the Config File Editor plugin.

Your templates are stored on your flash drive. If you tried to use one of the standard templates then you will have overwritten your previous template with that one. Do you have a flash backup?

Also, you should post your diagnostics so we can see if we can help figure out how you got into this situation to begin with.

Are you using the Previous Apps feature on the Apps page?

The failed write which disabled the disk, and any subsequent writes to that (now emulated) disk, are still emulated by updating parity, so they should be recovered on rebuild.

That is not your docker run command. Did you look in the Docker FAQ for instructions as I told you to?

It is always safer to rebuild to a replacement and keep the original in reserve in case there are problems with the rebuild. But, you can rebuild to that same disk if you want. I don't recommend shuffling things around to other disks when there is already a disabled disk in the array since all disks must be read to get the data for the disabled disk, so that is just a lot of additional unnecessary activity on an array that isn't protected. The only thing I usually recommend is if you don't already have backups (you should) you can copy anything important and irreplaceable from the emulated disk to another system or to an Unassigned Device. Before doing anything though you need to see if there is anything that needs to be fixed so you can successfully rebuild. SMART looks OK for that disk as you say, but you might run an extended SMART test on it anyway. And, of course, make sure all connections are good.

If not then it won't work as before, so make sure you do your homework on this.

You must have done something in your Krusader docker setup. Your Krusader screenshot by itself is not evidence that there are multiple folders on the flash drive. It is only evidence that there are multiple mappings in your Krusader docker. Post your docker run for Krusader as explained in the very first link in the Docker FAQ in the Docker Engine subforum.

Not at all Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

And you should consider how you want the pool to be setup if you continue to use different sized disks. Default raid1 only gives a mirror with total capacity equal to the smaller of the 2 disks.

Unraid will make folders on other disks as needed. Until high-water is reached, they aren't needed on the other disks yet.

You don't install it. You put it on another flash drive and boot it up.

Might make a small difference in specific situations. such as when you are writing to multiple data disks simultaneously. But the speed of writing any disk in the parity array will be dictated by the speed of the slowest disk involved, whether that disk is the parity disk or a data disk. Probably you won't really notice any difference. Write speed to the parity array is always going to be slower than the write speed of a single disk, because the data to update parity has to be determined and parity written at the same time. There are 2 different methods for determining the data to write to parity, and they have tradeoffs. See here for the details: https://forums.unraid.net/topic/50397-turbo-write/