trurl

Another possibility is your appdata wasn't on actual storage. In which case, it would not survive reboot. Have you ever had appdata that wasn't new after rebooting?

I thought perhaps cache had all your docker files as it usually does, but now it is missing for some reason. That would be an explanation for why appdata had to be recreated from scratch. If you never had cache, nothing in your diagnostics or your descripton that would explain it.

Both of those are in diagnostics. But there should be more

Have you never had a cache drive?

Attach Diagnostics ZIP to your NEXT post in this thread.

Some older syslogs aren't included in those. What do you get from command line with this? ls -lah /var/log/syslog*

Post diagnostics now, then setup syslog server to capture syslog for posting after crash.

Not clear it would help. Better if you figure out why it's crashing. Attach Diagnostics ZIP to your NEXT post in this thread.

Unless Syslog Server is setup, logs don't survive reboot.

Post another screenshot of syslog server settings.

I don't know specifically about how large attachments can be, but might be something to consider. Lots of different ways photos can be stored and some are very large.

You should always have a current backup of your flash drive in any case.

If original disk11 still has its data, you could just format disk11 in the array, and copy its data from the original disk as an Unassigned Device.

Do you know how the ransomware got in?

Do you have a current backup of your Unraid boot flash?

Don't know if the upgrade is to blame or not. I have been running with cache since before any V6 existed. The shares that it thinks should be using cache are exactly the shares that normally "prefer" cache by default. There are good reasons to have those specific shares on fast storage and not on the parity array. Do you actually have any Dockers or VMs?

That is the correct command. So the "original disk" doesn't have disk11 data on it? It is disk12 data? Do you have backups?

Shouldn't be any timing issues if you aren't trying to run any scripts before the array starts.

The version of Unraid you are using can only boot from a flash drive. Unraid OS doesn't install to any of your storage. The OS is unpacked fresh from archives on flash at each boot, into RAM, and it runs completely in RAM. Think of it as firmware. Was one of your SAS drives assigned as cache? Your diagnostics show 10 SAS drives, 2 as parity and 8 array data disks. How many SAS drives do you have installed?

A.I. demand is the excuse given for rising disk and memory prices. Preclear might get those pending sectors converted to reallocated sectors. Then you can see if it will pass an extended self-test.

Do you have an SSD in your server? That is what would usually be assigned as cache, but we don't see any SSD in your diagnostics.

go runs before the array is started. The only storage that actually exists at that point is /boot (the boot flash drive).

Several ways to get the command line wrong for that. Better if you stick to the webUI for check filesystem, it will use the correct command. What command did you use?

For future reference, if emulated disk is unmountable, you should check filesystem on the emulated disk BEFORE rebuilding, especially if you are going to rebuild on top of the same disk. The emulated contents are exactly what rebuild will result in. You don't want to rebuild an unmountable filesystem on the same disk that might actually still have your good data on it.

Looks like repair of disk12 was very successful, nothing in lost+found. So the original drive was disk12? Why did you mention the "original drive" when you were explaining what you did with disk11?