trurl

Diagnostics will give us a lot more information than just the results of that SMART test. It might even tell us more about the problems on your other thread(s). Be sure to get us the diagnostics without rebooting since syslog resets on reboot.

I just responded on your other thread. Probably whatever problem you have there is the cause of your problem here. Would you like me to merge these threads for you? I don't see any point responding to this thread until you fix your other issues.

Impossible to give any more information until you give us more information. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Just do a New Config without those disks and rebuild parity. If they have anything on them you want on the array just mount them as Unassigned Devices and copy the data.

Why are you even bothering with those small external disks anyway?

As you have seen, USB connections are too unreliable for the parity array or cache pool. The only way I would consider USB for the array is if it was strictly a backup array, and parity wasn't used. Otherwise, you will constantly be rebuilding due to disks being disabled and out-of-sync with parity.

Not sure I understand your problem, or your statement of it isn't complete enough for me to understand. Maybe if you more fully explained what you "normally do". Why can't you just "move" from one share to the other like you normally do?

You could just get a 4TB to build parity on, then another 4TB to replace/rebuild disk1, and keep the others for now. Then you can replace them with 4TB later as needed since you will already have parity large enough.

Go to Settings - Docker, disable dockers and delete the docker image. Do the same for Settings - VM Manager. Do you have any VMs? Leave these disabled until cache is installed, then you can invoke mover to get appdata,domains,system shares moved to cache. @Hoopster pretty much covered everything else I was typing.

This is exactly what I do (and I suspect most people do). The warning is saying it could overwrite files in the destination path. If the destination path specifies a subfolder of a user share, it won't go up a level and overwrite other things.

Fewer disks require fewer ports, each additional disk is an additional point of failure, larger disks perform better. Saw you mentioned 1TB SSD for cache, so maybe the 120GB SSD was just an Unassigned Device involved in the data load?

Disk3 is just CRC. You can acknowledge that by clicking on the warning on the Dashboard and it will warn again if it increases. Unfortunately, disk1 is more serious: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 187 Reported_Uncorrect -O--CK 100 001 000 - 23516 I would replace that ASAP. Hopefully you can build parity so you can do a replacement. I see you have a 1TB unassigned, it also has a warning but that is just a single Reported Uncorrect. But you might as well skip using that one as parity if you intend to replace your disks with 2TB soon. Parity must be at least as large as the largest single data disk, so you would have to build 2TB parity before you could replace any data disks. You might consider using that 1TB as disk1 instead of that bad one you already have in that slot. That would require working through some things to make that replacement since you don't currently have parity. Also see you have 120GB SSD. That is too small for much use caching user share writes, but should be fine if you only use it for dockers and VMs. And as I already mentioned, enabling dockers before installing cache wasn't the best idea. That will also require working through some things to get your dockers on cache where they belong. Personally, I would skip over 2TB and build a server with at least 4TB disks, using fewer disks if you can't afford it.

Hope you resolve your networking issues.

Also, would have been better if you had installed cache before enabling dockers.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Just some advice on using the forum. When you edit an old post to supply new information, many people will never see the new information, because we are looking for threads we haven't read yet. Your old post doesn't show up in our list so we never come back to it.

You should start your own thread and post Diagnostics.

If you know the correct disk assignments you just need to delete config/super.dat from the restore and it will make you assign them. The danger is having it autostart with a data disk that it thinks is parity.

Maybe but you should check parity in that case to make sure. Maybe something would show up in diagnostics. In any case USB parity disk is just a problem waiting to happen in my opinion whether it is the cause or not.

Since it's parity and new config will rebuild parity anyway, it only has to be as large as the largest single data disk.

USB connections are not reliable enough for disks in the parity array or cache pool. The only way I would even consider USB in the array is for a backup server with no parity disk assigned. Probably only a matter of time before parity gets disabled.

Do you mean your parity drive is connected by USB?

Interesting. I don't have preclear installed so I guess it creates that category. Maybe some other plugin you don't have installed creates the System Information category.

Yes, only one new config / parity rebuild at the end.