trurl

Also

Probably unrelated, but why do you have 200G allocated to docker.img? Have you had problems filling it? 20G should be more than enough and if it grows you likely have some application writing to a path that isn't mapped. Making docker.img large will not fix that problem, it will just make it take longer to fill.

johnnie.black addressed the main thing, but some other things to consider. You shouldn't run for long on batteries. The point of having batteries is so you can cleanly shutdown, not so you can keep running. Is your UPS compatible with the APCUPSd builtin to Unraid? Why do you have 50G allocated to docker.img? Have you had problems filling it? 20G should be more than enough, but I see you are already using 18G. I suspect you have some application misconfigured and it is writing to a path that isn't mapped. Also, your system share has files on disk1 instead of all on cache. Possibly this happened when you recreated docker.img while still having cache problems, or maybe you enabled dockers / VMs before you installed cache. Your dockers/VMs will keep those files open, so array disks can't spin down, and they will have their performance impacted by slower parity.

Excluding disks I assume?

Also, that driver is already included. Are you sure you don't have some actual hardware problem (cable, port, switch) with your network connection?

Do you have any spare ports? Try to use your intel ports and not the Marvell ports.

There isn't any way to install drivers in the GUI or otherwise. What version of Unraid are you using?

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

USB connections are not reliable enough for the permanent connections required in the array or pool.

Pairing HDD with SSD sort of defeats the purpose of having SSD since it will only work at HDD speed. And if redundancy is what you had in mind you apparently didn't accomplish it as shown by johnnie.black. I assumed you were just combining capacity so no redundancy since that is what your screenshot showed. You also need to consider getting those ReiserFS disks converted.

No syslogs in diagnostics only include since last reboot. You will have to get the syslog server logs and attach separately. Don't recommend leaving syslogs saving to flash but fine for short term debugging.

Here is how that goes in case you need it. Settings - Docker, disable, delete. Enable again to recreate docker.img. If you had any custom docker network such as proxynet you will have to recreate it. Then be sure to use the Previous Apps feature on the Apps page, which will reinstall your dockers just as they were.

According to your earlier diagnostics, it was configured to be 20G, which is the size I usually recommend. And it was only using 13% of that space, which is normal. If it ever looks like it is going to fill up then you have an application writing to a path that is not mapped. You can see how much of docker.img is being used on the Dashboard. And you can see how much of each disk is used by each User Share with Compute... for the User Share. If you want me to check how things are after your fixes post new diagnostics.

All you really need is the config folder from the backup. How recent is that backup? Does it have the correct disk assignments?

I think there is something related to config/super.dat (your disk assignments) with a trial key. I have never needed to deal with that. Make sure you have a screenshot or something in case you need to reassign your disks. Hopefully someone else will chime in with more information.

One cause of user shares "breaking" is filesystem corruption, but nothing in your diagnostics suggests that. In fact, as mentioned, they don't even indicate your user shares are broken. When this happens, can you access each of your disks in putty? Your syslog has messages that seem to indicate you have disabled ECC in BIOS. If so, why? Not obviously related, but have you seen this?

Unclear if you have you done memtest on this new hardware lately. The reason I suggested it is because your syslog is full of segfaults from your containers. Bad RAM is a possible cause. I guess another possibility is corrupt code in docker.img. I see you have 30G for docker.img. I usually recommend 20G and often ask if there is some reason the user has set it larger, though usually only when they have set it very large. Have you had problems filling docker.img?

USB not recommended for array or pool disks.

Looks like that is also Marvell

Those diagnostics are still showing you have user shares. Did you take them before stopping/starting? Seems unlikely that a container would cause this. Just to make sure there isn't some misunderstanding, what are you looking at from putty that shows your user shares are gone?

Any drive that fails SMART test should be replaced. Why would you do this? Why do you think you need 2TB for cache anyway? There are also some things about how you have dockers / VMs configured and using your shares that I would change. Why do you have 40G docker.img? 20G should be more than enough unless you have something misconfigured. Personally I would go for replacing SSD cache and not even have another in the pool unless it was another SSD. Since you apparently don't care about redundancy in cache might as well just go with a single SSD. Since cache appears to be readable and not a lot of used space currently, you might just move it all to the array, create a new SSD only cache with new SSD(s), and then work on getting those things moved back to cache that belong there. Currently your domain and system shares have files on the array anyway so that could use some work as well as recreating docker.img at a more reasonable size.

Might be useful for us to know why you want to downgrade. Might even be useful to you in case you have some problem that you have incorrectly attributed to this version.

You have a share anonymized as H----------k set to cache-prefer. Prefer means try to keep files on cache. Is that what you intend for this share? Or do you really mean for it to be moved to the array? To get it moved to the array you must set it to cache-yes. Your isos share is also cache-prefer. Since that share is normally used for iso files used to install VMs, but not actually used while running VMs, that one can be moved to the array also (cache-yes). Doesn't look like you actually have any VMs. The shares that should be on cache and set to stay on cache are appdata, domains, system. These are all cache-prefer, which is good, but system has files on disk1. Possibly you enabled dockers before installing cache, so docker.img got installed on disk1 instead of on cache where it needs to be. Mover can't move open files, so that is why it isn't getting moved. In fact, it is really better to just delete docker.img and recreate it. Then the Previous Apps feature on the Apps page will reinstall your dockers just as they were. Do you have any custom docker networks such as proxynet?

Typically you want files related to dockers / VMs to stay on cache so their performance will not be impacted by parity updates and so they won't keep array disks spinning. We can get a better idea of your situation from the Diagnostics. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.