trurl

I thought user0 was deprecated and no longer used by Mover.

I'm not sure it will help anything at this point, but go to Settings - Scheduler - Mover Settings and Enable Mover Logging. If that results in new syslog entries, post syslog. Let me know either way.

Make a backup plan. You don't have to backup everything, but you absolutely must have another copy of anything important and irreplaceable. Setup Notifications to alert you immediately by email or other agent when any problems are detected. Don't allow a single problem to develop into multiple problems. Go to the Apps page and install Fix Common Problems. Pay attention to any warnings it gives and correct them. As mentioned: And as also mentioned: Get diagnostics before rebooting if possible. Better yet, also setup Syslog Server so syslogs will be saved instead of being lost on reboot: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601 If we had the saved syslogs, we might be able to give a more definitive answer to what happened to cause all this. And seek advice on the forum before doing anything.

Just to clarify, since the reddit post seems to be about a previous occurrence. Are you saying you did New Config again just now? If that is what you are saying then you basically skipped ahead and did this: with no safety net. Not really surprising that it worked out though. Clearly invalid parity was at least part of the problem. Unraid disables a disk when any write to it fails. After disabling, Unraid will not use the disk again for either read or write, since its contents are presumed to be invalid (the failed write) and out-of-sync with parity (which was updated as if the write succeeded). Until the disk is rebuilt, Unraid will emulate the disk using the parity calculation to get the data for the disk by reading parity plus all the other disks. It does this whether reading or writing the emulated disk. For writing the emulated disk, it continues to update parity, so those writes can also be recovered with rebuild. In your case, since parity was invalid, the emulated disks were unmountable, so those emulated disks simply couldn't be used at all. And the contents of the actual disks were just as they were when they got disabled. Just wanted to get this out there. I will have more to say about what you should be doing in the future.

Those are OK. Usually a temporary connection issue. You can acknowledge them by clicking on them and they won't warn again unless the count increases.

How did you let this go? The only acceptable number of parity errors is exactly zero.

The simplest approach would be to just restore from backups of course. Do you have backups of anything important and irreplaceable? If so we could just proceed with formatting these disks and move on.

As mentioned, the disks ARE emulated, they are just unmountable. Maybe not emulated well due to invalid parity and other issues. Realized I left out a step in my instructions earlier I'm not sure whether you figured out that missing step yourself or not. I assume it would not actually do the check without the array started in Maintenance Mode. I missed that. So how to proceed? Repair emulated disks, then rebuild to new disks, keeping the originals. Then if needed mount the originals Unassigned, repair if necessary, and try to recover any files the rebuild didn't get. Or some other approach involving dd_whatever?

Looks like you were talking about disk5. It has more problems than you mentioned: Serial Number: WD-WCC4E1XJRHNC ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 163 163 140 - 1100 196 Reallocated_Event_Count -O--CK 056 056 000 - 144 197 Current_Pending_Sector -O--CK 199 199 000 - 782 198 Offline_Uncorrectable ----CK 200 200 000 - 378 Definitely Do you know how to rebuild to a new disk?

Might still be good to get an answer to this:

After checking cables/connections post a new diagnostic.

Not for many people who have somehow gotten parts of appdata onto the array. I seldom look at diagnostics where I don't see appdata and system shares partly on the array. I think many just don't understand the Use cache setting and others set up their dockers before adding cache so that all got created on the array and mover can't move open files so they get stuck on the array even if they have the use cache setting right. I have written many paragraphs about this in multiple threads.

Post new diagnostics

That looks good. The green "thumbs up" in the SMART column would be a yellow "thumbs down" if you had SMART warnings. Go to Main - Array Operation and Stop the array. Go to Main - Array Devices Click on Disk4 to get to its page and Check Filesystem. Be sure to capture the output so you can post it. Do the same for Disk6.

Diagnostics are after reboot so don't include the events. Setup Syslog Server so you can get syslog after crash. https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601 Have you done memtest?

You absolutely must NOT do that. You should never mix disks and user shares when moving or copying files. Cache is a disk and cache is also part of user shares. That is scenario #1 I talk about here: https://forums.unraid.net/topic/61985-file-browser-in-webui/?do=findComment&comment=723474

SMART for disabled disks looks OK. Do you have any SMART warnings on the Dashboard for any of your other disks?

Backup flash drive. Prepare flash as new install. Copy config folder from backup and you should be back as before.

Go to Tools - Diagnostics and attach the complete Diagnostics zip file to your NEXT post. Diagnostics includes syslog and many other useful things. Diagnostics are always preferred instead of only syslog.

The drives are emulated, but unfortunately the emulated drives are unmountable as shown in the screenshot. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post. Then wait on further advice. You really should have asked for advice before this since you say this has happened before.

Nothing obvious except most of your disks are still ReiserFS and your docker image is twice as large as necessary. Can you ping your server when it "crashes"? Do you have an attached monitor and keyboard? Have you done memtest? Setup Syslog Server so you can save the syslog from before the crash and post it next time it happens. https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601

Let's try again. Go to Main - Array Devices and post a screenshot. Be sure the screenshot includes the Errors column. Go to Dashboard and post a screenshot of the Array section.

Go to Tools - Diagnostics and attach the complete Diagnostics zip file to your NEXT post. It contains syslog and many other things. Diagnostics is always preferred instead of just syslog.

Your syslog is full of errors on multiple drives. Do you not see any Errors on the Main page? You have more disks than I care to examine. Do you have any SMART warnings on the Dashboard? Since it is affecting multiple disks maybe a controller or power issue. Also you probably have some misconfiguration of your dockers since you have allocated 50G and have already filled 19G of that. 20G allocated should be more than enough. And your system share has files on the array.

No SMART for cache in those but looks like it may be a problem with the device instead of just the filesystem.