itimpi

I cannot see any sign in the posted diagnostics that the notification about unclean shutdown was ever sent😒. Are you sure you got it this time around?

What was wanted was to copy between User Shares and a UD managed drive - did not think this solved that ?

In theory it should not make any difference, but is ZFS housekeeping accesses drives then that could slow down the parity check.

If you really need a GUI mode file manager then you could try installing the Krusader docker container.

Not clear why but you suddenly started getting read errors on all your drives (parity, disk2, disk2). Likely to be something they all share.

Afraid not. his is the first time I can remember this happening without there being some outside factor to explain it, and even then it is a one-off thing. It is possible someone else may have a suggestion.

You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to the reboot. If using the mirror option the syslog file is stored in the 'logs' folder on the flash drive. Unraid should not shut itself down without being actively told to do so in some way. It is also worth pointing out that if you have the Parity Check Tuning plugin installed then it has an option to restart an array operation from the point previously reached on rebooting (as long as it was a tidy shutdown and not a crash) which might prove useful to you?

It is worth pointing out (in case you missed it) that you can easily make a local backup at any time by clicking on the Boot device on the Main tab and selecting the backup option. The appdata backup plugin also has an option to make a local copy of the flash drive any time it runs.

Not quite sure I understand your question? If you write to an 'emulated' disk then parity is updated appropriately so that Unraid can continue to emulate the disk correctly (including the new data just written).

You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. If using the mirror option the syslog file is stored in the 'logs' folder on the flash drive.

Not easily from a running system that I know of. The plugin now detects an unclean shutdown by the presence of the 'config/forcesysc' file on the flash drive during the boot phases as that is created by Unraid when it starts the array after a clean shutdown and deletes it when it successfully stops it. If you can get at the USB drive while it is not in Unraid you can check for that but by the time you start booting it is probably too late.

I think that this is a current restriction in FileManager in that it will only allow you to work with physical drives OR User shares - not mix them. Ideally it should allow devices managed by Unassigned Devices be used when working with User Shares but currently does not.

This would not harm (although it is time consuming). It is not unheard of for brand new drives to fail almost immediately, particularly if they have had any rough handling in transit to you.

Not an answer to you issue, but you have a lot of .cfg files in the config/shares folder on the flash drive for shares that do not currently seem to exist. It might be a good idea to delete the ones that really are spurious to clean up any future diagnostics.

How are you sure? Lots of people get them without realizing it as it can happen when you press the Shutdown or Reboot button if a timeout kicks in or if for any reason or if Unraid cannot write to the flash drive during these sequences. About the only way to be certain you have not had one is to successfully Stop the array before attempting to Shutdown or Reboot. At the moment I am waiting for someone on the latest release.to be able to give me some diagnostics (with the plugin ‘testing’ logging mode active) to confirm that there is still a problem with the Unclean shutdown detection. I have not managed to spuriously get one in my recent testing when actively trying various scenarios to force iit.

It tends to mean that something changed at the hardware and/or bios level so it is definitely something I would be worried about.

The reason for doing a preclear is that as well as clearing the disk (thus avoiding the need for Unraid to do it) it also acts a stress test for the drive so that you can avoid adding drives that do not pass pre-clear error free. Pre-clear does take longer than the clear process though.

Something must have changed. Sometimes it is something not obvious such as the drive not reporting the same size for some reason (even 1 byte off will cause this).

Note that those two transcode paths are different as they have different capitalization and Linux is case sensitive. You need to work out which one the container thinks it is using and then set that one up correctly and remove the other one. My guess would be the second one is the more likely. Also you should map the transcode to something like /tmp/plex (i.e. not the top level of /tmp) as otherwise plex may remove file it should not from /tmp.

I would check file system on the drives associated with the shares as file system level corruption has been known to cause this sort of issue.

You cannot. Parity is not that clever - it only knows that something has gone wrong somewhere. The sequence of the way that the writes happen that as long as a drive has not failed a lost write to the parity drive is far more likely than the data drive so this is the assumption that is made. The only way to make sure that a data drive does not have bad data is to either have checksums for the data or use BTRFS or ZFS as the file system type as they have built in check-summing. This is one of the reasons we recommend that the scheduled parity check is set to be non-correcting so that you only run a correcting check when you think none of your data drives has a problem.

If you are on the latest release of the plugin (2023.09.06) then there is a good chance it IS genuine but it would be nice to make sure. If you enable the 'testing' mode of logging in the plugin's settings and once this has happened post a copy of you system's diagnostics I can check whether it is genuine. It should also be present in the Unraid syslog but you have to find it there.

You can look at the top right of the GUI when running Unraid.

The link is via clicking on a notification - I do not see how embedding the link in the page can be leveraged from a notification? I wonder if it can be embedded in the text part of a notification in some way - might need to try that next.

No idea I am afraid. That part of the scheduling is handled by the core Unraid system and not by the plugin. Maybe you need to raise a feature request/bug about this?