trurl

On mobile now so can't look at Diagnostics. Go to Settings-Syslog Server and you can configure where to save syslog.

This seems to indicate you are using the UPS wrong. You want Unraid to shutdown fairly soon after the UPS indicates power was lost. Trying to run your server on battery until the battery dies is a bad idea for several reasons.

yes This seems to indicate some confusion about what the docker image is. You can reinstall using the template or the Previous Apps feature on the Apps page. But just restarting the container should do it. Plex will see the codecs don't exist and will get them.

And since you didn't actually answer these questions, here they are again:

That thread is nearly 3 years old, and 6.2 isn't supported as I mentioned on your other thread. I just reviewed that entire thread, and that user was trying to run on a marginal (at best) PSU. And the whole thing about 6.2 was as compared to 6.3, not compared to any more recent version. And here is a much more recent post from that same user which includes diagnostics that show that user is currently running 6.7.2: https://forums.unraid.net/topic/84900-parity-errors-but-no-unclean-shutown/?do=findComment&comment=787857 So I think you might as well forget about 6.2 as the solution to your problems. There are lots of threads where a user thinks they have the exact same problem as another user (and they think that is a good reason to hijack the thread for some reason), but further diagnosis reveals their problems were completely different. If you do want to try a slightly older (and arguably still supported) version see the DOWNLOAD page linked at the top of this page.

Here is how "unclean shutdown" works. You must stop the array before rebooting or shutting down. If you shutdown or reboot from the webUI or command line then Unraid will attempt to stop the array before rebooting or shutting down. I think if you briefly push the power button Unraid also recognizes that as a command to shutdown and tries to stop the array first. If you pull the plug, or hold the power button or press the reset switch if you have one, then Unraid doesn't have a chance to stop the array, so you get an unclean shutdown and parity check. Unraid stores the started/stopped status on flash. If it successfully stops the array then it will try to write that stopped status to flash. If for some reason it can't successfully write the stopped status, then when it boots it will think the array wasn't stopped and will begin a parity check due to unclean shutdown. Let us know if your user share problem is fixed now.

IDE instead of AHCI is not recommended. Are you overclocking? Don't. Have you done memtest? You need to get us more information. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your next post. Also, if you are on 6.7.2 or higher, go to Settings and Enable Syslog Server so you can save syslog to give us after a crash.

Unraid 6.2 is no longer supported and is so old it is unlikely to work with many plugins and probably other things. Definitely not recommended. How old is the forum post you read? Looking at your other thread, I don't know what the solution is. I will reply further on that thread.

Each disk is an independent filesystem, no striping. Each disk can be read separately from the others on any linux. Only disks being accessed need to spin. Each file is completely contained on a single disk, but folders (user shares) can span disks. One or two parity disks provide redundancy. Read speed is only as fast as the single disk being read, and writes are somewhat slower than single disk due to realtime parity updates. Because each disk is independent, different sized disks can be used in the array, and disks can be added or replaced without rebuilding the whole array. Here is the Wiki on how Unraid parity works: https://wiki.unraid.net/UnRAID_6/Overview#Parity-Protected_Array

You can have up to 2 parity disks. The parity disks don't have to be the same size as each other. Each parity disk must be at least as large as the largest single data disk. So, you can replace one of your parity disks with the new 4TB and keep the other 3TB parity disk, then use the old 3TB parity disk you replaced as a data disk in a new slot. In that case, all your data disks would still be only 3TB, so each of your parity disk must be at least 3TB. One of the parity could be 4TB and the other parity could be 3TB since one parity disk can be a different size than the other parity disk. If you did want to go to single 4TB parity, then both of the old parity disks could be reused for data. Tell us how you want to proceed. Since you are going to rebuild parity in any case, if you New Config you could add the data disk(s) at the same time and not have to wait for them to clear.

Actually, what I saw in your diagnostics was m___a(1).cfg since it was anonymized. Possibly if you look at your not anonymized diagnostics then you see it as Media.cfg Deleting that .cfg will not have any effect on your files. It will only make the user share have default settings. Then you can make the settings again. Take a screenshot if you need to.

What do you get when you try to boot now? Possibly it is just a case of the BIOS resetting so it isn't trying to boot from the flash now.

And booting from a USB2 port is often more reliable also.

No, but each parity drive must be at least as large as the largest data disk. So, to put it all together, you can use the new disk as one of your parity disks, but you cannot use it as a data disk because neither of your current parity disks are large enough.

Other way around. If allocation method had precedence then split level would have no meaning. According to your diagnostics, your media(1).cfg has settings. This is likely the Media.cfg file you are seeing. But there is no share by that name (no files). The media share itself has default settings, and that is the share that has the files. You might try deleting Media.cfg, reboot and make settings for the media share to see if that clears up the confusion.

Are you booting from USB2 port? That is often more reliable.

On mobile now so can't look at Diagnostics, but filesystem repair isn't the fix for a disabled disk, that is for unmountable disks. The disabled disk is emulated and should be rebuilt. You should be able to even read the files on the emulated disk assuming it is mountable. Wait for someone to look at your Diagnostics and give you advice before trying anything else.

As suggested, probably you formatted the disk when it was in the array so you rebuilt a formatted disk. Format means "write an empty filesystem to this disk". That is what it has always meant in every operating system you have ever used. Unraid treats this write operation just as it does any other, by updating parity. So after formatting a disk in the array, parity agrees the disk has an empty filesystem, and rebuilding that formatted disk results in an empty filesystem. Format is never part of the rebuild process.

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

Have you done memtest?

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

Sounds like your flash is disconnecting. It is best to use a USB2 port for the Unraid boot flash. We can get a better idea if you post your diagnostics. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

It isn't ongoing, it is an issue in the current stable, fixed in release candidate. Upgrade to release candidate or wait on the next stable.

https://forums.unraid.net/bug-reports/prereleases/how-to-install-prereleases-and-report-bugs-r8/

In case you still need something to fill in your understanding Array = disks in the parity array /mnt/user/subfolder = a user share named subfolder User shares always include cache. Unless the share is set cache-no then all new writes go to cache.