trurl

I am not sure I understand. What would be the purpose of adding the old disk4 that you have already copied back to the array. In a certain sense (no valid parity) you don't really have an array, just a bunch of separate disks.

Reboot and post new diagnostic. It shouldn't be necessary to redo flash.

Unraid IS NOT RAID. Unraid needs the controller to let it access the individual disks. I don't have experience with those but often you can configure their BIOS or maybe reflash. Maybe someone else will have more specific information.

That seems a little faster than I might expect for rebuilding 4TB. Possibly it will take longer than the current estimate shown. I usually estimate 2-3 hours per TB.

I was going to respond over there since this is locked now, but it is also locked over there, and most of what I wanted to say have nothing to do with the version anyway, so I will respond here and since @aladdin134 might need to respond to my comments, I am also unlocking this thread. @aladdin134 There is a share anonymized in your Diagnostics as G-------) Could this be the share you mean? It is cache-prefer for some reason and it is all on cache. On the other hand, your system share has files on the array. Probably you created docker and libvirt images before you added cache so they got created on the array instead of cache where they belong. And I see you have given 80G to docker image, and are already using 28G of that. This most likely means you have one or more of your docker applications misconfigured and the app is writing into the docker image instead of to mapped storage like it should. Unless you have something misconfigured, it is extremely unlikely you will need even 20G, and 20G is what I always recommend for the size of docker image. Making it larger doesn't help anything, it just makes it take longer to fill and become corrupted. Do you have any VMs? The best way forward with your docker image is to go to Settings - Docker, disable, delete it then recreate it at only 20G. That will get it on cache where it belongs then Apps - Previous Apps will install your dockers just as they were. But, just as they were isn't the end of it since you have something wrong somewhere. Make sure each place an application is configured to write anything is writing to a mapped path. Common mistakes are not using the same upper/lower case in the application as you used in the docker mappings, or not using an absolute path, beginning with /.

Better to just let Unraid manage the btrfs raid cache pool, various configurations are supported: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/#comment-480421 The total size required for cache depends on how you will use cache. If only using cache for dockers/VMs performance and not caching User Share writes, a large cache isn't needed. This is how I choose to work since my writes are mostly scheduled backups and queued downloads, so I'm not sitting around waiting for them to complete anyway. Others choose to work differently. If you do want to cache writes to User Shares, then you will need larger cache, enough to hold as much as you intend to write between scheduled moves to the array. But keep in mind that you can't move to the array as fast as you can write to cache. Mover is intended to work during idle times. And best to leave cache out of it for the initial data load since cache won't have the capacity to take it all and will just get in the way. Some even leave parity out of the initial data load so they don't have the overhead of realtime parity updates, then build parity later.

And the templates won't go away simply by removing plugins since the dockerman "plugin" is builtin. Maybe getting us the diagnostics will tell us more. They don't often include much about specific dockers, but they might give us some idea about your actual User Shares. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

Not entirely clear what you mean by a \ share. Maybe if you could tell us exactly what path you fat-fingered it would clear things up. If you mean the host path was literally \ then that would go away with a reboot as long as the docker is gone and doesn't recreate it, since all the paths at that level are in RAM. If that isn't what you mean explain further.

And the templates won't go away simply by removing plugins since the dockerman "plugin" is builtin. Maybe getting us the diagnostics will tell us more. They don't often include much about specific dockers, but they might give us some idea about your actual User Shares. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

Not entirely clear what you mean by a \ share. Maybe if you could tell us exactly what path you fat-fingered it would clear things up. If you mean the host path was literally \ then that would go away with a reboot as long as the docker is gone and doesn't recreate it, since all the paths at that level are in RAM. If that isn't what you mean explain further.

You have a lot of login attempts from all over the place. You must NOT put your server on the internet. Fix that problem before considering anything else.

I think you mean to rename the .plg file in the config/plugins folder.

On mobile now so haven't looked at Diagnostics yet. Bad connections are much more common than bad disks. Check all connections, power and SATA, both ends, including any power splitters. Then post new Diagnostics.

I recommend using fewer, larger disks instead. Likely some of those aren't new and maybe not reliable. Fewer disks require fewer ports, less power. Larger disks perform better due to increased density. More disks require more license. Most importantly, more disks are more points of failure.

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

Probably you have an old version of Community Applications too so that might be the problem. Why don't you upgrade? If for no other reason than old versions are difficult for us to give support.

That is pretty far away from the default network.cfg. Try renaming it and reboot so the default can be regenerated, then go from there.

Looks like itimpi covered most of it, but I just want to comment on this bit: Parity is not a substitute for backups. Many of us don't backup everything on our large capacity servers, but you must have another copy of anything important and irreplaceable.

I think the btrfs filesystem has some sort of snapshot capability but since I have no experience with that I'll let others comment. The way Unraid handles replacement of disks there isn't really any point to hot swap of disks in the array. You must go into the webUI and stop the array, assign the replacement disk, and start the array to begin the rebuild. On the other hand, you can "hot plug" disks not in the array and use them with Unassigned Devices plugin. Your question about hot swap makes me think you may have some other things that need clearing up though. Unraid IS NOT RAID. It has some similarities to some RAID configurations, but each data disk in Unraid is an independent filesystem, no striping. This important difference makes it possible to add disks to Unraid without rebuilding the array, and to use different sized disks in the array. There is also one or two parity disks that provide some redundancy so you can recover from a failed disk. Check out the Product pages linked at the top of this page and this Wiki Overview: https://wiki.unraid.net/UnRAID_6/Overview

What version Unraid? https://forums.unraid.net/bug-reports/prereleases/sqlite-data-corruption-testing-r664/?do=findComment&comment=6650

Dockers can only see drives that are already mounted when the docker engine starts, UNLESS you use the slave mode in your mapping. So unless you have it setup that way you can expect the problem to continue to occur whenever you restart.

In future, please consider zipping these or just attach your diagnostics since diagnostics already contains the complete syslog. Do you have Syslog Server configured so syslogs are retained after rebooting? Sorry see we already discussed in this thread.

Might be useful to consider how you got into this state. Do you have Notifications setup to alert you immediately by email or other agent when a problem is detected? You must address a problem immediately so you don't wind up with multiple problems you can't recover from. So your array is pretty much gone except for disk3 and all you can hope for is to rescue / copy files from the other disks to somewhere else. Do you have backups of anything important and irreplaceable? Do you have a backup plan? Many of us can't afford to backup everything from our large capacity servers, but you must always have another copy of anything important and irreplaceable, preferably on another system.

Is there is any data on these existing disks that you want to keep? Unraid must format any disk it will use in the parity array or cache pool.

What exactly is the volume mapping you are using with the container?