itimpi

That was not meant to be checked into github - I will have to revert it until I have finished testing my current changes. I was only intending to check in the source file changes - not the .plg file.

That is strange. - I did not think I made a release at that point. There has not been a release since last year as far as I know. I have been working on changes recently to support the UnRAID 6.9 multi-language feature and I think these are nearly complete so there is likely to be an update sometime in the next few days which IS meant to be there and will include this new feature as well as a number of minor fixes.

If none of them are showing as orange then you have already acknowledged any CRC errors and will only be told if the value changes. Note that this value can never be reset to 0 - it can only increase so you just want it to be stable.

Can we get the order of the releases displayed by the plugin reversed so that the newest release shows at the top? This is generally more efficient as most users will want one of the more recent releases. In addition there have been a number of cases in the forum recently where users clicked on the top entry without realizing it quite an old release an thus inadvertently downgraded because they did not scroll to the bottom of the list.

Yes for a manual check. for a scheduled check it is on Settings -> Scheduler where you set the schedule.

The problem is that it is not possible to pin the cause of a parity error to a particular drive. is your regularily scheduled parity check set to be correcting or non-correcting? It is recommended that you have it set to non-correcting so that a mis-behaving drive does not end up corrupting parity. If it IS set to be non-correcting then the error will quite likely keep occurring until you run a correcting check. you mention the next check running ‘next week’. This is probably unnecessarily frequent, and most users run the check only once a month or even less frequently.

The diagnostics show that you are getting lots of resets/retries on device ata8 (which I believe is your cache disk) and this could explain your symptoms. The SMART information on the drive looks OK at first glance but one this is not a definitive proof that the drive is OK. i would suggest that the following is a good cause of action in the short term. Carefully check the power and SATA cabling to the drive as a bad connection can cause this type of symptom run an extended SMART test on the drive to check its health (this can be done from the dialog that results from clicking on the drive on the Main tab). if after doing that you still get the same symptoms then I would suggest taking new diagnostics at that point to see if anything else is showing up.

It would trigger a downgrade because you have just told the system to revert to that release. I have suggested before that the plugin should present the list of releases in the reverse order so that the most recent ones are at the top of the list as a number of users seem to have accidentally downgraded by clicking on the top entry. If the list order was reversed this would be less likely to happen.

In fact the whole of the parity disk is always used, so if it had a utilisation it would always say 100%.

This will be a limitation of the USB external bay you are using. Many external bays DO present each drive with a unique ID to Unraid and so work fine. Having said that it is worth mentioning that is is not recommended that you have array drives connected via USB as USB connections tend to not be reliable enough for array drives. USB is typically used for removable drives that are only temporarily connected to an Unraid system (typically for back-up or data transfer purposes)

The first step will be to post your system's diagnostics zip file (obtained via Tools -> Diagnostics) taken shortly after you have experienced the problem to see if we can spot something.

You can but performance will be degraded if you do so until parity rebuild completes so you do not want to write any significant amount.

The SMART information for that drive looks OK. At the moment UnRAID is emulating the drive - now that it is mounted do the contents look OK? The steps you outline will make UnRAID attempt to rebuild the contents of the emulated drive back onto the physical drive.

From the SMART information I would say: Disk2 is probably fine. CRC errors are connection related and are typically related to the power/SATA cabling to the drive rather that the drive itself. Occasional errors are not really of concern but regular ones mean you should carefully check the cabling. The point to note is that the CRC errors count never gets reset, so if you click on the orange icon for the drive on the Dashboard and select the Acknowledge option Unraid will then only tell you about it again if it changes. disk3 looks as if it may be on the way out. It has lots of reallocated sectors and pending sectors. You could run the extended SMART test to confirm it is not well. the syslog in the diagnostics were taken just after a reboot so there is nothing to show what lead up to the current situation.

According to that report only the ‘short’ SMART test has been run - but that failed anyway.

With that many reallocated sectors I would expect them to accept a RMA regardless of the result of the Extended SMART test.

Security enhancements in UnRAID means that files on the boot drive are not allowed to have execute permission. Script files therefore either needed to be preceded by the command name e.g. sh path-to-script-file or they need to be copied elsewhere and their execute bit set (typically using entries in the config/go file on the flash drive) before trying to use them. If they do not need to run as part of the boot sequence then the User Scripts plugin is another way to run them.

This does not look too good: While reallocated sectors are not necessarily a problem as long as the numbers stays constant anything other that a small number is often a good indication that the drive's health may be suspect. You might want to run an extended SMART test on the drive to see how that goes.

Are you sure you have the correct name for the mount point of the UD disk? (‘disk8’ is an unusual name). If you have got it wrong then that command will end up writing to RAM instead of the disk.

I think you have mis-understood the purpose of `MacinaBox’. You only get the option to run the VNC viewer when you start your Mac VM. what the plugin does is generate the files that are required to run a Mac VM - it is not a VM in its own right.

The drives have been disabled because a write to them failed, not necessarily because the drives have failed. Frequently the problem is not the drive itself having a problem but an external factor such as the SATA/Power cabling to the drive. Posting your system diagnostics zip file (obtained via Tools -> Diagnostics) might allow for some informed feedback on this.

This is expected as the default for a cache pool is to set it up as the btrfs version of raid1 for redundancy . If you want to switch to a different profile then this can be done by clicking on the cache on the Main tab

I am afraid not. I assume it is the partition type and the sector it starts on but that is just a guess.

You can change the configuration dynamically with btrfs by clicking on the cache entry on the Main tab.

The problem is likely to be that UnRAID expects a very specific partition layout and it sounds as if these drives partitions do not conform.