trurl

Definitely a user error, and one that can crop up in other ways. Linux is case-sensitive, as simple as that. If you use different case you are specifying a different path. Better check all your docker mappings. Better check the settings within each of your docker applications also. A mistake there is the most common cause of filling docker image. If the application specifies a path that uses different case than the mapping, then that path is not mapped and so is inside the docker image.

If you want help you need to give more information.

The relevant post in the FAQ: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=480418

Would be simpler and might make even more sense to just remove the smaller of the 2 since it arguably doesn't add much capacity to cache that is already 1TB.

The FAQ post directly after that one already linked. https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=480421 You want "single"

The first thing you need to do is decide on your cache pool configuration. Do you want it to be a mirror raid1 like it currently is? If so then you are wasting most of that NVME, since you can only mirror the smallest of the drives. Or do you want to use the full capacity of both but without any redundancy? No point in worrying about anything else until you get your cache pool configuration stabilized.

Plug it in to a USB2 port and leave it there.

I have added SMART attribute 1 and 200 to my notifications on the WD Reds, I think it was @johnnie.black who recommended it. Based on those, the fact that it failed extended test, and the fact that it may have been handled badly, I would not use it. Unraid must be able to reliably read every bit of parity PLUS every bit of ALL other disks in order to reliably rebuild a missing or disabled disk.

@johnnie.black This brings up a question on the diagnostics. Do the diagnostics show what raid configuration cache pool has? @ani3114 Assuming default raid1 configuration, your cache pool is a mirror with only 240GB capacity.

Since this seems to be a case of shooting yourself in the foot, I expect this report will be downgraded to "Minor" if not moved to General Support instead, but I will leave it for now. I'm pretty sure there is already a check for cache with mover but maybe it doesn't work in your scenario. But, your scenario is not entirely clear since you didn't post any diagnostics, that snippet of syslog is incomplete at best, and you didn't give any clear directions for how to reproduce the problem. For future reference, here is the guideline on posting a bug report: https://forums.unraid.net/bug-reports/stable-releases/report-guidelines-r68/ This seems to be the most important part of your post, but it is also the part that is most unclear. I assume you mean you added the SSD to the parity array. SSDs aren't recommended in the parity array, but I will leave that for now. (The word "filesystem" usually means something else) There isn't any specific place where cache is enabled so I don't know what you mean by that part. If you mean there were user shares set to use cache I don't think that would matter. I know cache-yes and cache-prefer would just overflow to the array. I'm not entirely sure what cache-only would do without cache though. Is there something else you had in mind when you said cache was enabled? Could you give a more complete, step-by-step, description of what exactly you did, that stuff that you only summarized in the part I quoted above?

SSDs in the parity array are not recommended and are considered experimental at this point. SSDs in the array cannot be trimmed, and there is some question whether some implementations could invalidate parity. Put the HDDs in the parity array and the SSDs in cache pool or as Unassigned Devices.

Plenty of ways to lose data that don't involve a failed disk. User error is a lot more common than disk failure, for example.

For future reference, you can download a zipped backup of flash at Main - Boot Device - Flash - Flash Backup. You should always have a current backup of flash. Take a new backup anytime you make significant changes in the webUI. This is especially important if you make any disk assignment changes (add, replace, remove).

You can get a replacement license key once per year using the automatic process. More than that then you have to plead your case to limetech to get a new one. And in any case you need that backup of flash so you won't have to set everything up again. And you should boot from a USB2 port regardless.

No not as a first step, since replacing it requires you to get a new license key. Try what I suggested first.

Flash drive problem. Put flash in your PC and let it checkdisk. While there make a backup. Try booting from a USB2 port, they are more reliable for the Unraid boot device.

That's basically it. But I have to ask, do you have another copy of anything important and irreplaceable? Parity is no substitute for a backup plan.

You need at least one disk to start an array with, and Unraid must format any disk it will use in the array or cache pool. If you can empty one of those disks, preferably one of the larger ones, you can use it to start, then mount one of the other disks with the Unassigned Devices plugin and copy its files, then add it to the array, repeat.

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

yes

memtest on the boot menu.

With only one data disk, the parity disk is a mirror of that single data disk. Did you assign the new disk as parity?

works for me now also

Forgot to ask, since you have more disks than I wanted to look at. Are any of your other disks showing SMART warnings on the Dashboard?

Double check all connections first, then to rebuild disk13 instead of the disabled disk11 see this post: https://forums.unraid.net/topic/86439-my-10tb-disabled-itself-and-now-my-4tb-did-on-rebuild/?do=findComment&comment=801957 except you would use invalidslot 13 29