trurl

And what was that edit? An edit shouldn't have been needed for the upgrade since you didn't overwrite it. For many purposes, User Scripts plugin is better than editing go anyway.

By "anymore", do you mean it did work but now it doesn't? The Unraid OS is in RAM and a fresh copy is loaded from flash at each boot. So any change you might have made in /usr doesn't survive reboot.

Exactly how did you use that download to upgrade your existing install?

That screenshot of /boot/config/shares is not as useful as I had hoped since it isn't presenting them in alphabetical order. And all of the screenshots are pretty small to read. Did you really intend to have so many user shares?

Do you know how to use that download to upgrade your existing install?

Cache will just get in the way of a large transfer since it won't have the capacity, and there is no way to move from cache to array as fast as you can write to cache. Mover is intended for idle time. Best to leave cache out of any initial data load. Something you can do to increase write speed to the array is to not install parity until after the initial data load. Then you won't have the overhead of parity updates. There is also another method of updating parity that is faster. The 2 methods and their tradeoffs are explained here: https://forums.unraid.net/topic/50397-turbo-write/

You have an unusually large number of user share configuration files on flash. Some appear to be duplicates, and many are not actually user shares with any contents. Possibly some of these shares were created by accident by some of your dockers. Go to Shares - User Shares, click the Compute All button at the bottom. wait for the result. It will probably take several minutes. Then post a screenshot. Also, go to Main - Boot Device, click on the folder icon at far right for flash to drill down into its contents. Then click on config, then click on shares, then post a screenshot.

You have used 31G of a 50G docker image. That almost certainly indicates you have one or more of your applications misconfigured and they are writing into the docker image instead of to mapped storage. I always recommend allocating only 20G for docker image (less than you have already used). Making it larger won't fix your problem, it will just make it take longer to fill. Typically the way this happens is an application is set to write to a path that doesn't correspond to a container volume mapping. Common mistakes are not using an absolute path, or not using upper/lower case that matches the mappings. Another way you can misconfigure a docker is by using a host mapping that doesn't correspond to actual storage. That will result in a docker writing into RAM. Note that any mapping to an Unassigned Device that isn't actually mounted will also be in RAM. The way forward for this is going to be deleting docker image, recreating it at the more reasonable size of 20G, then using the Previous Apps feature of the Apps page to reinstall your dockers just as before. But just as before isn't good enough, so doing it one docker at a time to consider what you have wrong with the way each one is setup. But before that let's wait and see if we get another opinion on what to do about your cache drive. Maybe for now just disable the docker service and wait. Possibly that might even make your crashing go away. I have some things to say about your user shares. I will start a new post for that.

The reason for the warning is because frequent writes to flash are not good for its life. It is possible to configure Syslog Server to write to something else such as a user share. But for quick troubleshooting, using flash is OK as long as you remember to turn it off. I think you may have to backup cache and reformat it. I'll see what @johnnie.black thinks about that.

https://forums.unraid.net/topic/50866-help-please/?do=findComment&comment=501310

Those things in the log in your first post suggest a problem communicating with the cache disk. Likely a bad connection or cable. I notice Fix Common Problems warnings in the syslog in your diagnostics. One of those warnings says you have syslog mirrored to flash. I think that must mean you have Syslog Server setup. The sylog in your diagnostics only has information since the last boot, but Syslog Server saves syslogs indefinitely, and they might tell us more about what happened before the reboot. Post those syslogs from your flash, preferably zipped. I see a lot of other things in your diagnostics that show things are configured wrong, but probably best to take this a little at a time.

Not in Unraid, it has to be done before booting Unraid. Memtest is available on the boot menu.

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post. Have you done memtest?

Unraid must format any disk it will use in parity array or cache pool. If these are individual ext4 disks you can access their data with Unassigned Devices plugin and copy the data to the array then reuse the disk. Do you have backups or anything important and irreplaceable?

Just in case you don't know. Only btrfs allows multiple disks in cache. If you ever decide to have more than one disk in the cache pool again, then you will have to reformat that xfs cache.

Unraid disables a disk any time a write to the disk fails. This is because it is no longer in sync with the parity calculation. In the case of a data disk getting disabled, the write to the disk failed but the write to parity succeeded, so the contents of the disk are no longer valid, but the correct contents are represented in the parity array and can be rebuilt to the disk. In the case of parity getting disabled, the write to parity failed, so it is parity that is out of sync with the data in the array. Unraid will not use a disabled disk until it is rebuilt. In the case of a disabled data disk, instead of reading or writing the disabled disk, Unraid emulates the disk. To read the contents of the emulated disk, it uses the parity calculation to get the correct data for the disk by reading parity plus all the other disks. To write to the emulated disk, it reads the emulated disk as explained, then updates parity as if the disk were being written. So even though Unraid has ceased to use the disk at all, the initial failed write, and any subsequent writes to the disk, are represented in the parity array and can be rebuilt to the disk. In the case of a disabled parity disk, parity is no longer written, but writes continue to the data disks, so parity is out of sync. And, of course, if you have a disabled disk in a single parity array, whether that disabled disk is parity or data, then you no longer have any redundancy. Single parity allows only one disk to be rebuilt. Dual parity still has redundancy when a single disk is disabled, and loses redundancy when 2 disks are disabled. Dual parity allows 2 disks to be rebuilt. Looked at SMART for your parity disk, it seems OK. Often these problems are caused by bad connections, cables, etc and not by a bad disk. You can rebuild parity (or indeed any disk) to itself by Stop array Unassign disk to be rebuilt Start array so changed assignment is registered Stop array Reassign disk to be rebuilt Start array to begin rebuild

I had never looked at that one, I'll have to remember that. I did notice too much total capacity for cache in df.txt

Also, I assume you know parity is disabled? I didn't notice in syslog that you were rebuilding parity. Are you?

You can see how much space each user share is using on each disk by going to Shares - User Shares and clicking on Compute... for the share, or just click Compute All at the bottom. You can "drill down" into a User Share by clicking its folder icon at far right on the User Shares page, then clicking on a folder name as you go deeper. You can "drill down" into a disk by clicking on its name on the Main page, then clicking on a folder name as you go deeper. Other than viewing folder contents, there is no way to manage the files and folders in the webUI. What are you wanting to change?

You can get to the command line inside any of your dockers by clicking on its icon on the Dashboard or Docker page and selecting >_ Console

Would have been better to get us complete Diagnostics with the server still up. You will have to rebuild the disk to enable it again.

Take a look at the other posts in the FAQ under the Cache Drive/Pool section: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=554741

Mover can't move open files. The best way to take care of this is to completely disable docker service. That will also allow you to delete docker image so you can recreate it at a more reasonable size. Then run mover to get appdata moved. Then after reenabling/recreating docker image, the Previous Apps feature on the Apps page will reinstall your dockers just as they were.

And raid0 will give total capacity without mirror. Also see here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=480421

btrfs will allow raid1 with 3 disks, which will give you more capacity than just a simple mirror of 2 disks. See here: https://carfax.org.uk/btrfs-usage/