trurl

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.

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.