trurl

If BIOS can't see disks Unraid can't Try reseating controller, checking all connections, whatever. No doubt your data is fine you just need to resolve your hardware issue.

Oct 9 07:01:42 teletraan kernel: md: recovery thread: recon D4 ... ... Oct 9 15:37:14 teletraan kernel: md: sync done. time=30932sec Oct 9 15:37:14 teletraan kernel: md: recovery thread: exit status: 0 OK https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui Be sure to capture the output so you can post it.

I wouldn't even use the word "added". Rebuild / replace is always to the same slot, adding is to a new slot.

If there is a speed problem with the actual disk, and you use the same disk for rebuild, then expect rebuilding to also have a speed problem.

You will always get a parity check after unclean shutdown: Oct 9 09:29:03 192 emhttpd: unclean shutdown detected

What version Unraid? You may need to run the latest beta to get your NIC supported.

I assume you mean rebuild of disk4 is completed, since that is what that invalidslot command would have done. Maybe before doing anything else you should post new diagnostics just so we can confirm.

In Disk Settings, you can globally set warning and critical utilization, and in the Settings for each disk you can override those. But none of that does anything to prevent filling the disks, it just gives warnings and notifications. Each user share has a Minimum Free setting. You should set Minimum to larger than the largest file you expect to write to the user share. When Unraid chooses a disk to write for the user share, it will choose a disk that still has more than Minimum. And Minimum Free won't keep you from filling a disk either. If you set Minimum for a user share to 20G, and a disk has 25G remaining, the disk can be chosen, even if the file is 30G. Unraid has no way to know how large a file will become when it chooses a disk for it.

The purpose of UPS is to allow safe shutdown, not to allow running on batteries. If you run the batteries down you will have to let them recharge sufficiently before starting your server again or you won't have enough battery for safe shutdown. After a short time on batteries, you can assume the power is going to be off for an unknown time and it should just go ahead and shutdown.

Unclean shutdown results in noncorrecting parity check. If the parity check you are doing now is correcting it should fix them. To confirm they are all fixed another noncorrecting parity check. Exactly zero is the only acceptable result and if your most recent parity check doesn't have zero sync errors you don't know if you still have a problem.

The templates have the paths as previously configured. Just use the Previous Apps feature on the Apps page to use the templates.

The only good thing about all the wrong things you did was you didn't format the emulated disk. Best to ask before making things up without really knowing what to do.

You should rebuild unless you have some good reason to suspect rebuild will not produce a good result. A disabled disk is out-of-sync and rebuilding will get it back in sync. The alternative is to rebuild parity instead to get the array back in sync, but the disabled disk is the one that is out of sync. See this recent post for more details about this:

I prefer the word "bay" when talking about physical location of disks, and "port" when talking about how they are connected. I reserve the word "slot" for talking about the disk assignments since that is how those are referred to in syslog. You can remove both parity disks and replace them with the new larger disks, assign those to the parity slots, and start the array to build parity on both. Or you can do them separately if you want. I usually expect 2-3 hours per TB. Be sure to always double check all connections when mucking about in the case.

You are overthinking this. Just configure each user share to have the access needed.

And step 2 is usually called "emulate". Nothing is really "created". It just reads parity and all other disks to calculate the data for the missing disk using the parity calculation.

There is no point in step 4 (probably some confusion about the meaning of format), and at step 5, it won't clear the disk, it will rebuild it. Even an empty disk is rebuilt since it needs to be made in sync with parity again. If the disk has an empty filesystem, it will be rebuilt with an empty filesystem. Another possibility would be, after step 3, New Config without the disk and rebuild parity. Then you would be protected again, and could proceed however you wanted with testing that disk, and later add it or a new disk (Unraid will clear added disk so parity is maintained).

It is usually better to rebuild than to assume a disabled disk is correct, because it is probably out-of-sync. Unraid disables a disk when a write to it fails. A disabled disk isn't used again until rebuilt (or New Config as you did before). But writes to the array continue. In the case of a disabled data disk, the disk is emulated from the parity calculation. That original failed write, and any subsequent writes, update parity, so those writes can be recovered by rebuilding. And so the disabled disk is out-of-sync with parity. In the case of disabled parity, any subsequent writes to the array are not written to parity, so it is out-of-sync with the array. To rebuild to the same disk, whether data or parity Stop array Unassign disabled disk Start array with disabled disk unassigned Stop array Reassign disabled disk Start array to begin rebuild

yet

You have a cache-only share anonymized in diagnostics as d-------s (downloads perhaps?). Why is that a cache-only share? There are probably better ways to do whatever you are trying to do with that.

But it might make more sense to reconsider how you are using cache. Cache should only need to be as large as needed for those things that stay on cache (appdata, domains, system shares) plus enough to cache data for a typical single day of writing to whichever user shares you think need to be cached. If you are needing to write a lot more than typical for some reason, such as the initial data load, then don't use cache.

Single mode is what you want instead of raid0