trurl

You have important incompatibility warnings on the list.

Can you explain the parity errors you got on previous checks? Since there weren't many perhaps they were from unclean shutdowns. Have you always shutdown cleanly from the webUI? And why are you checking weekly? Most people only check monthly. Parity is maintained realtime and a parity check isn't required to have valid parity. But clean shutdowns are. As for the MCEs, have you done memtest?

Rebuilding a disk requires all the other disks. Parity is just a bit that allows a missing bit to be calculated from all the other bits. Without the other disks there is no way to rebuild.

Where exactly are you seeing the "correct time" on your server? Something is wrong somewhere if your logs are not showing the correct time.

You should always try SAFE mode before making a bug report, and you should always include diagnostics in bug report:

If you have set your downloads share to cache-no, then it will not be moved from cache. Mover only moves cache-yes from cache to array, and cache-prefer from array to cache. Mover ignores cache-no and cache-only shares.

Also, cables from modular power supplies are not standard and should not be mixed up with cables from others

Does it happen if you boot in SAFE mode?

Are your sure your server can reach the internet?

Often the motherboard manufacturer will have a list of memory which has been tested to work. Sometimes they can be very picky.

Or maybe a browser problem. Do you have multiple browsers or tabs accessing your server? I'm not sure but I don't think this docker can actually have an effect on the webUI since it just opens a console inside the container.

Have you done memtest?

You should never clear an SSD, and it is debatable whether you should preclear that other disk since it is already well beyond "infant mortality". Preclear is really only for testing and burning in disks since Unraid will clear a disk anyway in the one and only situation it requires a clear disk (adding a disk to a new data slot in an array that already has valid parity). This sounds like a problem with flash, but nothing else in diagnostics or that additional syslog to indicate that. Have you done memtest?

You must actually disable dockers in Settings - Docker and the same for Settings VM Manager since these services will still have open (unmovable) files even if you stop the individual dockers/VMs

I know this post is a little old, but since there are new posts in this thread, I thought it needed some elaboration in case someone is trying to follow it. This "classic method" is missing some important details. It seems to imply that there are only 2 possible Use cache settings, but there are 4, and which you use at each step is critical. Here is the more complete information. Instead of stopping all VMs/Dockers (that is not enough): Go to Settings - Docker and disable Dockers. Go to Settings - VM Manager and disable VMs. Stop all writing to all user shares by anything. Set all user shares to cache-yes. This is the only setting which will move from cache to array. Run mover to get everything moved from cache to array. Swap cache drive. Set shares you want to stay on cache to cache-prefer. This is the only setting which will move from array to cache. Typically, you want appdata, domains, and system shares on cache. Set other user shares to whichever Use cache setting you prefer. Run mover to get those shares you want to stay on cache moved back to cache. Enable Dockers and VMs. Also, don't do this:

Seems more like a Flash problem. Go to Tools-diagnostics and attach the complete Diagnostics zip file to your NEXT post.

Did you find this in the FAQ?

I copied your report here to General Support since that is where it belongs. If we decide it is really a bug we can reopen your report. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

Copied to General Support where it should have been posted and locked this thread. Changed Status to Closed Changed Priority to Other

Yes that needs replacing. Where did you read this? If a drive is failing a parity check makes no sense because the failing drive can cause parity errors, and if replacing parity it also makes no sense because parity is going to be completely rebuilt on the new parity drive. Unraid will clear a drive when ADDing it to a NEW DATA slot in an array that already has valid parity. This is so parity will remain valid since a clear disk is all zeros and those zeros have no effect on parity. Doesn't apply in your case since you are not ADDing a disk to a NEW DATA slot. Note that is the only scenario where a clear drive is required. Any use of preclear beyond that is strictly for testing purposes. Just go ahead and replace / rebuild parity, then we can talk upgrade.

Also, setup Syslog Server: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601 When you reboot syslog resets (it's in RAM like the rest of the OS) so the diagnostics don't contain what happened before the reboot. But Syslog Server will let you save syslog somewhere you can retrieve it after reboot which might give some clues.

That will not harm the disks, but the fact it is increasing might mean the disk isn't reliable. Keep an eye on it. As for the hangups, have you done memtest?

You can go directly to the correct support thread for any of your dockers by simply clicking on its icon and selecting Support. But since this is a question about how to use plex rather than how to setup the plex docker, you might find your answers at the plex website.

Typo, he meant disk share. If you aren't sharing disks on the network might as well just call it disks. In either case, you shouldn't mix disks and user shares when moving/copying. In general, the user share settings only apply to new writes to the share, except the Use cache setting of course. Any read of a share will include any disks that include the folder for that share. Another thing that happens down at the linux level that can be surprising is that if you try to move something from one user share to another, it will just get "repathed" on the same disk. This is because the linux command for move and rename are the same, mv. So, even if destination user share excludes the disk, it still winds up there. The workaround for this is to copy from source to destination, so a new file gets written according to the user share settings, then delete from the source.