itimpi

If the parity disk is still assigned then Unraid will still be trying to update it even though you have not finished creating valid parity. There would be no difference in performance between pausing it and cancelling it.

I have just updated all my plugins and I am getting the same FCP warning, so despite what the release notes for the last FCP update suggest it does not handle this issue yet. I expect we will see an update to FCP issued later today but I can understand wanting to ignore it until then.

Those network speeds look consistent with the transfer rates you mentioned so it is the network limiting transfer speeds.. What type of networking are you using as the speeds appear to be very low.

At the Unraid end is the share set to be Public or one of the more restrictive access modes.

It looks like an update to FCP was released yesterday to address this. Have you installed that update?

According to the diagnostics the files mentioned are indeed corrupt (they should contain human readable text). This suggests the flash drive may have problems. The flash drive is formatted as FAT32 which should be readable on any system so you can always take the flash drive out of the server and plug it into another machine to both check it can be read and to make a backup by simply copying its contents. In practice it is only the contents of the 'config' folder that really matters for backup purposes as this contains all your settings.

The extra columns only get populated for checks that are run after the plugin is installed. If nothing else this will allow you to get confirmation of whether Unraid started a correcting or non-correcting check as the plugin looks at the characteristics of a running check (i.e. AFTER it has been started) and not what it was set to be at the time it was initiated. Just a thought though, you might want to make a small change to the settings page for the scheduled check and hit apply just in case the displayed fields are not matching the stored ones on the flash drive as doing that should cause them to be rewritten.

You can, or simply wait for an FCP update.

In another thread has been mentioned that this folder is being created as a result of a recent change to the UD plugin and the FCP plugin needs updating to stop flagging this folder as unexpected.

There is the ‘addons’ folder which is not standard. What is this being used for? Edit: It appears that this folder is being created by a recent change the Unassigned Devices plugin and FCP needs updating to account for it.

Not really. I would suggest you boot in Safe Mode. If it does not go wrong then that suggests a plugin is the issue. If it still goes wrong I would be looking at docker vontainers.

It is not clear how those permissions could go wrong in the first place as they should be set to the correct values any time Unraid is booted. That suggests something is actively changing them to the wrong values after booting.

No - it would say it was a parity-sync if it was building parity rather than checking it. if you install the Parity Check Tuning plugin then for new checks the history entries will tell you if the checks are correcting or non-correcting. This will happen even if you do not use the plugin’s facilities to run checks in increments.

According to the diagnostics the flash drive temporarily dropped offline (it later reconnected) : Mar 2 19:23:31 Server kernel: usb 1-4: USB disconnect, device number 4 Mar 2 19:23:31 Server kernel: FAT-fs (sdb1): Directory bread(block 30018) failed and you then got errors every time Unraid tried to read and/or write any configuration information from the flash drive and unfortunately Unraid does not normally handle tidily the flash drive going offline even temporarily Ideally you should use a USB2 port (possibly via a header on the motherboard if there are no external USB2 ports as USB2 has proved far less likely to suffer from such issues. There is a "Flash Remount" plugin that might be worth installing to see if it helps.

Have you tried changing the start order in the docker tab and where appropriate adding delays between docker starts to allow any dependencies to complete initialising before whatever tries to use them?

Since you seem to have the syslog mirrored to flash it would be useful to post a copy of that syslog so we can see what lead up to the crash. The diagnostics only include the RAM copy which started afresh after the last reboot.

That does not look good I am afraid. Not sure of the best way to proceed at this point @JorgeB tends to be the best expert on these things but I expect he has gone to bed by now (as I am about to do myself). This might be a case where we try and use the ‘emulated’ drive rather than the physical one if parity is good but I would like to see what others think before suggesting this route.

I have no experience of using S3 Sleep as I simply shutdown my servers overnight rather than sleeping them. There might be issues with the S3 Sleep not bringing the system back in the correct state I guess on coming out of sleep mode. You did not actually mention what the status line said about the exact operation that was running? May not be relevant but thought it was worth checking.

The link was about running a file system check - not a parity check What are you actually running? The file system check is normally quite quick.

One way to achieve that would be to set the Split Level on the Media share to 1. You then create the Media folder (if it does not already exist) on each drive and folders for the next level down on the disk you want them to be on. The Split Level setting will then constrain them to the disk on which you have created the second level folders. You could also use level 0 for Split Level (manual management) and it would achieve a similar result. This may be more intuitive?

It is NOT mounted - or it would not be showing as unmountable according to your screenshot. The drive has not, however, been disabled. Running just the check is a read-only operation so it will not change anything and the output from that gives an indication of what the state of the disk actually is.

I do see is the following message in the syslog: Mar 2 21:44:59 Moulin-rouge Parity Check Tuning: Send notification: Automatic unRaid Parity-Check will be started: Unclean shutdown detected (0.1% completed) which means the plugin think there was an unclean shutdown. Thinking about it that message might need to be reworded slightly as it could be some other array operation that was happening at the time so it is not always a parity-check. What operation does it actually say is in progress on the status line? However I also see this: Mar 2 21:44:30 Moulin-rouge kernel: mdcmd (36): check correct Mar 2 21:44:30 Moulin-rouge kernel: md: recovery thread: check P ... which I would only expect if Unraid thinks it needs to be building parity (the normal default automatic check would be non-correcting).

If you want someone to look at them you have to actually post them

It needs to be FAT32 - vFAT will not work properly.

Have you tried installing and using the Dynamix File Manager plugin? Might be the easier thing to do if it satisfies your needs and it is aware of how Unraid User Shares operate and can protect against certain operations users sometimes do that lead to either unexpected behaviour or even data loss.