itimpi

No idea why your system should use so much space under /run. On my system the space used is more like 4MB so 32MB is more than enough.

Pending sectors not being 0 is never a good sign as it indicates a sector that cannot be read reliably. Sometimes rewriting these sectors can clear that, but if not then the drive needs replacing.

No, but since even a single error is too many you should not need one.

The diagnostics show disks 2, 3, 4 and 5 dropped offline. Is there anything they share? Is perhaps the PSU struggling to power that many stoves?

You will need to contact support about this.

Yes, although I am not sure what the reference to disk share is about.

You would need to contact support for this. However once a drive is blacklisted as a result of a licence transfer I am not sure there is a mechanism for reversing this.

You have “Included Disks” set to All so the share is not restricted to disk16 even though that might be where all files are currently stored.

I think you are falling foul of the behaviour described in the Caution in this section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

I think the answer is yes as long as the share only includes one drive and has the array set as primary storage and no secondary storage. However the performance gain is likely to be marginal as it would still have the overheads of the Unraid parity mechanism on all write operations. Also the share would not be able to take advantage of the ‘cache’ mechanism. another way to think of this is what ends up being mounted as a single file system directly under /mnt. Each drive in a the main array is its own free-standing device containing its own file system and is mounted with a name along the lines of /mnt/disk?? Each pool also mounts a single file system as /mnt/poolname even though it might be multi-disk.

Just found you can get a similar error if the host path is set but there is nothing in the server path field.

That suggests the drive may really have failed since you seem to have checked all the obvious candidates. Can you tell if the drive is even spinning up?

Have you checked in the BIOS yet?

There is no sign of the drive that I can see in the diagnostics. I would carefully check power and SATA cabling. Does the drive show up in the mobo BIOS?

You may find that doing this helps.

The 6.12.7 release never appeared except as a rc - not sure why.

I have not heard of there being USB sticks that large that are not fakes. You might want to try running one of the many programs available that can test for fake uSB drives and report their true capacity.

Because I do not own the .page file in question and did not want to try and modify the standard file. However I wonder if I can add a hidden section to that page that does a refresh - something to look into.

Not really as Unraid does not provide an API, but not far off the move to v6 from v5 was definitely a breaking change as that reflected the move from 16 to 32 bit with no backwards compatibility for 16 bit support. We have no idea when (or even if) v7 will arrive and why the major number is to be incremented. the minor revision tends to mean some major new functionality. For instance 6.13 added ZFS support for the first time. It does NOT guarantee backward compatibility. the patch number DOES try to maintain backwards compatibility within the minor version but could break this if needed to fix a serious issue.

If you have explicitly set XFS as the format then Unraid will try and mount it using that format and fail if it is not XFS.

Not sure if it is fixed in the 6.12.7-rc2 release currently available. Also not sure if the Parity Check Tuning plugin being installed would get this message corrected or not. The plugin definitely gives the right value when it displays a notification but it may not be able to suppress Unraid giving the wrong one.

There is no way that Unraid can change the format by itself. Much more likely that you forgot what format it was in as the default is btrfs.

There has been a bug where the notification give the results of the previous check rather than the one that has just finished.

Your diagnostics are showing resets on multiple drives. Are you sure your PSU is capable of handling that many drives?

It gets stored in the location you specify in the syslog server settings.