trurl

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.

no Unraid disables a disk when a write to it fails. Simple as that. Disks SMART looks OK. Are these on the same controller?

https://wiki.unraid.net/Troubleshooting#Re-enable_the_drive

If the .plg files exist then they should reinstall themselves. In fact, the old installations are probably still on flash, but without the .plg files they won't be loaded on boot. Maybe there is something about the old installations that is breaking something. Each of those .plg files probably has a corresponding subfolder in /boot/config/plugins. You might try deleting those subfolders so they can get a clean install.

Those diagnostics are saying you have 63TB of files in user shares, with lots of user shares with files on the disks. Possibly you are having a browser issue instead. Do you have an adblocker or anything else that might interfere with accessing the webUI? If so, whitelist your server.

Make sure you don't mix disks and user shares when moving or copying.

yes Will work but not recommended.

Maybe one of your apps is storing large files directly in the database.

Very old thread but might as well use it. Go to Tools-diagnostics and attach the complete Diagnostics zip file to your NEXT post in this thread.

Check connections then post new diagnostics.

Note that this doesn't mean it won't use any of that "Minimum Free" space. For example, Minimum is set to 4GB. The disk has 5GB remaining, so it can be chosen. You write a 3GB file. Now the disk has 2GB remaining, and won't be chosen again.

Unraid has no way to know how large a file will become when it chooses a disk for it. If a disk has more than Minimum Free (in your case zero), the disk can be chosen, and if the file won't fit you get the error. You should set Minimum Free to larger than the largest file you expect to write to the share. So if you set it to 4GB as suggested, and the disk has less than 4GB remaining when it chooses a disk to write, it will choose another disk.

What about your disabled disk? You must take care of that immediately. Post your diagnostics.

If it works in SAFE mode and not otherwise that suggests a plugin issue. Which plugins were you using? From the command line, what do you get with this? ls -lah /boot/config/plugins/*.plg