trurl

After emptying the drives, you will have to New Config without them and rebuild parity. I don't recommend using older and/or smaller disks in the array just because you happen to have them. Each additional disk is an additional point of failure, requires more ports, more power, and at some point, more Unraid license. All bits of all disks must be reliably read to reliably rebuild a missing disk. Older and/or smaller disks don't perform as well as larger newer disks. Add drives when you need additional capacity, not just because you have some disks laying around.

Be sure to boot from a USB2 port

OK, finally finished getting the morning started. Have you started the parity rebuild yet?

If you had custom docker networks you have to recreate them after recreating docker.img, then you can select the custom network when you edit the container.

First, I am going to bed after this post, so if you want to wait I will check back tomorrow. I don't have your version in front of me obviously so some specific details may be slightly different, but basically New Config has worked the same since I have been using Unraid (4.7). It is just a way to reset your disk assignments, let you assign any disks however you want, and optionally (by default) rebuild parity. Any disk assigned to a data slot will not be changed. Make careful note of your disk assignments so you can be sure to get them all assigned correctly. It is especially important that you not assign any data disk to any parity slot, since it would be overwritten with parity. Go to Settings - Disk Settings and disable autostart. It shouldn't really matter but just in case. Then shut down, remove new disk3 and replace with original disk3. Reboot, then Go to Tools - New Config Not sure of the wording in your old version. It will probably let you keep your assignments as they are, or keep only some of them. It doesn't matter at that point, it is just for convenience that it lets you keep them, because Before starting the array, it will let you change any assignments you want to change. Keep all assignments as they were except assign the original disk3 to data slot3. Then, when you start the array, be sure that you don't check the box saying parity is valid, because it isn't due to a different disk3. Then starting the array will begin parity rebuild. If for some reason it shows any data disk is unmountable or no filesystem, DON'T FORMAT! Shouldn't happen except we don't know for sure about that original disk3. We can deal with repair later if necessary. Ask if you have questions. Post diagnostics and maybe screenshots if something doesn't seem right.

Total capacity isn't important for parity check speed. Size of the largest parity disk is the main deciding factor since the disks are read simultaneously unless you have controller bottlenecks. With dual parity an old CPU might be the bottleneck since parity2 is a more complicated algorithm. If you are confident your system is stable now, you can try to copy the data from that original disk3 to the new disk3. Copying the data would be simpler if you had the Unassigned Devices plugin, but if you don't, you probably can't install it without upgrading Unraid first. Or, you can New Config / Rebuild Parity with that original disk3 back in slot3. In any case, you should definitely upgrade. Upgrading has many advantages as mentioned, but upgrading from such an old version has a few details that may need to be worked through.

Was that after all these replace / rebuilds? I always recommend a non-correcting parity check after any rebuild just to confirm that the rebuild went as expected. Do you have port multiplier or something? My 8TB parity check always completes in less than a day.

Of course there should be no changes to user share settings, and there is no change. I always discourage sharing disks on the network anyway. Retaining disk share settings when those settings apply to a specific slot instead of to a specific disk and its data doesn't seem any more correct to me than to just have default settings applied to all disks and then let the user make any changes needed. I agree though that either way can be confusing for the user and making it more visible does make sense.

Parity operations ideally happen in parallel. Multiple disks are read at the same time. Trying to do that through a single port is going to be a bottleneck. Depending on the specific hardware, USB can cause other issues besides this bottleneck. For these reasons, option 3 seems like it is more suited to Unraid, with a separate connection for each disk. This is the way the vast majority of Unraid users have their systems configured.

Before trying to get that disk or its data back into the array, you should do a parity check to make sure your current setup is stable.

That is what I expected, but unfortunately your diagnostics aren't helping much. I've opened many of them. That disk appears in several of those older diagnostics in your first post, but for some reason, there is no SMART information for any disks in those diagnostics. And it doesn't appear in any of those newer diagnostics which does have SMART information for the disks. So, I can't tell if there is anything wrong with the disk or not. Do you have the Unassigned Devices plugin?

What are the last 4 characters of the serial number of that disk?

Even if you retain all you can still make any changes including changing slots so some default settings is probably the only thing that makes sense.

If you don't need the capacity yet I recommend not adding disks. Each additional disk is an additional point of failure. Older smaller disks especially don't seem worth it.

Cache is often used for dockers and VMs for performance. Unraid must format any disk it will use in the array. You may be able to mount the disk with Unassigned Devices plugin and copy its data to the array. What filesystem is it?

No. Parity must be at least as large as any single data disk, and can be upgraded.

I haven't looked at all those diagnostics you posted. Those you initially posted were a year or more old as noted. It is possible they have some relevance in this case though. I looked at the newest of these old diagnostics and it tells us what disk you had assigned to slot 3 a year ago. If that was the "original" disk3 when you began all these rebuilds, then maybe that is where we will find your files. The newest and oldest of this last batch of diagnostics you posted has a different disk assigned as disk3, but each of these diagnostics is showing the same for disk3, so it looks like we don't have a record of any other disk3 assignments between last year and now. So, was the original disk3 the same disk that was in that slot last year? If so, do you still have that disk and haven't changed it in any way since you removed it for replacement?

I will be back after lunch and help you figure out which disk was the original disk3. Please don't do anything else without further advice. For example, putting the original back in slot 3 will rebuild it with the current contents of slot 3, obviously not what you want.

I know I wrote a lot of information, and I encourage you to study it and ask questions. But for now, this seems to be the most important question for you to answer:

As mentioned, I could see you were having problems with disk7 in the first diagnostics I looked at. I didn't investigate further to see if there really was a disk problem since there was just too much to sort through before I got some more answers. You say you rebuilt disk7. According to those latest diagnostics, it looks like disk7 has plenty of data. Then you say you rebuilt disk4 and that is where you say format came into play. But disk4 also seems to have plenty of data. Then you say you rebuilt disk3. Disk3 is the one that seems to have been formatted, since it has little or no data, and you seem to agree it has little or no data.

Format is never part of a rebuild. "Format" means "write an empty filesystem to this disk. That is what "format" has always meant in every operating system you have ever used. Unraid treats this write operation exactly as it does every other write operation, by updating parity. So, after formatting a drive in the array, parity agrees the disk has an empty filesystem. Rebuilding a formatted disk results in a formatted disk. So that seems to explain why some of your data is missing. I am sure Unraid warned you about formatting the disk and even made you check a box to allow it to format. You say it said the disks needed replacing. I'm pretty sure it never says that. Unraid just disables a disk when a write to it fails. After it is disabled, it doesn't use the disk again. It doesn't continue to try to use it and possibly make things worse. Instead, a disabled disk is emulated by reading parity and all other disks, so reading the data for the slot can continue, and even writing of the data for the slot can continue by updating parity. Any writes to the slot can be recovered by rebuilding. But, it leaves the decision of how to fix the problem that disabled the disk up to the user. Re-enabling of the disk is usually a rebuild, possibly to the same disk if it is good. As I said, bad connections are much more common than bad disks. In a situation where you have been replacing disks or otherwise mucking about in the case, bad connections are almost always the problem. There are ways to decide whether a disk is bad or whether the problem is something else. Really wish you had asked for advice before doing anything at all. Probably at each step where you replaced a disk there wasn't really anything wrong with the disk. It sounds like you replaced a disk then formatted the replacement. What you probably should have done is repaired the filesystem then rebuild, or rebuild then repaired the filesystem. You definitely should not have formatted. Do you still have the original disk you replaced? It is possible we can recover your files from that original.

You should post them anyway since they would give more context and might even contain additional information that points to the issue which is causing lockups. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Also, I generally don't recommend moving data from the emulated disk, it just makes everything work a lot harder, since all disks must be read to emulate the disabled disk. And in the end, you need to rebuild anyway and rebuild will get the data back, so no point in going to all that extra work on yourself and your hardware.

I'm going to wait now for answers to these:

I'm trying to figure out where in all that information to look to see what your problem is, and the information in those old diagnostics don't help narrow things down as easily as newer versions. Plus, you posted so many diagnostics, any of which might show something important. Another reason to ask for help earlier instead of dumping all this on us at once.