trurl

Nobody requested that you have dual parity, we were talking about having 2 disks in the cache pool. What old version are you talking about? It has been this way for a very long time, but I see you joined the forum before V6. In V5 there was literally no way to have cache protected, since it didn't support multiple disks in cache pool. But it also didn't have anything to warn you of that fact. There is no way to have cache protected without multiple disks in cache pool. Either setup cache pool or just make sure you backup anything you consider important in cache and forget about that warning indicator.

https://wiki.unraid.net/The_parity_swap_procedure

Is that a shucked drive? Or are you trying to run with USB drives in the array? And how did you determine disk2 was dead? All 2TB drives may not be the same size, if they are using USB.

Many don't rely on which port is used but instead expect to see something that identifies the specific drive. And if it doesn't find it, it will try another, likely a hard drive that doesn't have an OS on it.

Are you sure your BIOS is set to boot from the new flash?

Flash drive has disconnected. Rebooting is the only thing that might help, and even if it did help it might be only temporarily and other things need to be done that can't be done remotely, such as plugging it into another port. Do you have a backup of flash? Are you booting from a USB2 port (recommended)?

I don't see any good way to dispense with drive serial numbers. DRIVE22 wouldn't have any meaning in many of the situations we need to deal with. There are disks that aren't assigned, disks that have been or will be used to replace assigned disks, disks that we may not know how they were or should be assigned. And many times any misunderstandings when discussing these things will have some chance of lost data. And I'm not convinced I've ever heard of a good reason to keep drive serial numbers secret.

Post diagnostics

If you have some suggestions for further anonymizing diagnostics let us know

I've not seen a hard copy of memtest before, but it seems to be saying you had errors. Is that true? The only acceptable number of memory errors is exactly zero. Everything ultimately goes through memory, data, executable code, everything.

This is a yes or no question: This seems to be a very ambiguous way to answer it:

Did it ever work after upgrading?

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601

Back before prefer was an option, yes or no or only seemed pretty intuitive. Now that we have prefer, yes and prefer are both confusing lots of people. Maybe we should give up on the one-word description of the cache options.

Maybe you have a Flash problem that prevents saving any setting. Go to Tools-diagnostics and attach the complete Diagnostics zip file to your NEXT post

Your welcome "Member"

You forgot this: 🤣

This does show he is writing to a path that isn't mapped, but the result of that would be to fill docker image, not fill RAM. In any case, go to Tools - Diagnostics and attach the complete Diagnostics zip file to your NEXT post.

Something that actually shows that 99% number. Is that from the Dashboard, or from System Stats?

I haven't had this problem ever in 6 years on my current flash drive. I literally and physically broke my previous flash before that and had to replace. I wonder if checkdisk is the most reliable way to deal with this though. It seems to me checkdisk could wind up having to just dump important things into .fsck files. Maybe the most reliable approach is wiping the partition then new install as seen in this post by @johnnie.black https://forums.unraid.net/topic/85785-server-wont-boot-panic/?do=findComment&comment=795122 Then restore config folder from backup.

May not matter as far as RAM usage goes. All of his mappings are to actual storage. The default transcode path for plex winds up in appdata, and if he has it set to something else that isn't mapped, it would wind up in docker image. Can you provide some evidence that it is indeed using that much RAM? Just to make sure there isn't some misunderstanding. Maybe you are just seeing I/O buffer.

NerdPack plugin to install Python: https://forums.unraid.net/topic/35866-unraid-6-nerdpack-cli-tools-iftop-iotop-screen-kbd-etc/ User Scripts plugin as mentioned to schedule script: https://forums.unraid.net/topic/48286-plugin-ca-user-scripts/ The user shares are at /mnt/user, so a Movies share is at /mnt/user/Movies. Note that Linux is case-sensitive. Python is not one of my native tongues so I will leave that as an exercise for the reader.

Yes, that could certainly be a reason for various and multiple recurring issues. And memtest should definitely be done if only to eliminate it. Though I wouldn't expect it to actually kill a flash drive.

syslog snippets are seldom sufficient Possibly that mover entry was simply the last entry in syslog before crash because nothing else was going on at the time. Do you have any particular reason to suspect that all your previous crashes happened at the scheduled mover time? Have you done memtest?

Just thought I would mention Diagnostics, since you're new and it wasn't mentioned in the thread. Tools - Diagnostics will let you download a zip file which contains many of your settings, SMART for all attached disks, syslog (since last boot), information about your shares, the results from running some simple commands, and other things which give a much more complete understanding of your situation. We usually prefer diagnostics instead of only syslog, but in cases of crash, it can also be useful to have syslogs from before reboot. And since diagnostics won't have those syslogs, Syslog Server is needed to get those for us.