itimpi

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.

This is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. The Unraid OS->Manual section covers most aspects of the current Unraid release.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You can 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. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.

This type of issue has come up before and I have a feeling there is a 'quirk' that Limetech can add to the next release to handle this, but it tends to be a drive model specific answer and not generic in nature. It also might be worth checking if there is a firmware update for the drives in case that solves the issue.

It looks like the problem might be that the SSDs are not reporting unique serial numbers and since that is the way Unraid recognises array drives this causes a problem.

You can set the spindown for the drives when they are idle which saves some power. if your system can support Wake-on-LAN then you might be able to have the system completely powered off most of the time and just woken up when needed if you are prepared to wait for several minutes as it powers up.

that log snippet suggests software initiated the shutdown. Do you have something like S3 sleep plugin installed as I believe that can shutdown the server unexpectedly. You might want to have the syslog server enabled (if you do not already have it enabled) to capture syslog entries leading up to he shutdown.

Are you intending to replace disk7, or are you looking to copy its data elsewhere and take the actions required to remove it from Unraid?

You normally want your 'system' and 'appdata' shares set to be only on a pool (cache) to maximise performance of docker containers. You can then enable Exclusive Shares under Settings->Global Share Settings to get even better performance by by-passing the Unraid Fuse layer for such shares. If the 'cache' pool is a single drive (and thus unprotected) you should install the appdata backup plugin to get regular backups made to another location (typically on the array). If you intend to use VMs then you may also want the Domains share set to be on a pool.

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. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.

@BrennstoffBernd I have just uploaded a plugin update that should fix the problem you encountered on getting array operations to restart. BTW: You do not need to pause the operation before stopping the array or using shutdown/reboot. If you do then the plugin will attempt to pause it after restarting the operation which may not be what you want?

Have you tried creating the flash drive using the Manual install method. In my experience it is more reliable than using USB Creator.

Btrfs does not accurately report space when using an odd number of drives. I believe that the Used is accurate, and that the Free space gets closer to being accurate as the pool starts filling up.

You might want to consider installing the Parity Check Tuning plugin and using its option to pause any parity check while mover (or appdata backup) is running.

Should there be a disk7? Currently the array is unprotected as you have single parity and a missing disk7.

I was wondering if anyone knows if there is a way to force the current GUI page to be refreshed from a script that has been initiated via cron or an Unraid event? The reason I want to be able to do this this is that if the GUI is sitting on the Main tab and the Parity Check Tuning plugin either pauses or resumes a parity operation the GUI does not enable the pause/resume buttons as I would like. Doing a manual refresh corrects this but it would be tidier if I could do it at an appropriate time from my code running in the background (i.e. not as part of a .page file).

Unraid is quite happy to run with parity2 present and no parity1. You can stop the array; unassign the parity1 drive; assign it to be disk2; and start the array. This will cause Unraid to initiate a Clear of disk2 (the old parity drive) and when it is completed you can the format the drive in preparation to using it. Note that you cannot move the parity2 drive to the parity1 slot without rebuilding its contents as the two parity slots use different calculations.

No. Hardware id is only relevant if it is being passed through to a VM. Unraid identifies drives by their serial number, not by how they are connected. As long as both old and new cards report this the same way the switch is transparent.

You should check if those files/folders already exist on the array? Mover will never overwrite an existing file, so if you have a file at both locations you have to decide which one to keep and manually delete the other (typically the older one). Dynamix File Manager can help with doing this.

Power or SATA cables can sometimes work themselves slightly loose simply due to vibration or thermal effects. I think the SATA cable is particularly prone to this as it is not a very robust connector.

When you change the PCIe slit then it’s hardware id can change. If the new id happens to correspond to some hardware that you passed through to a VM then this can cause problems as the vfio level isolation takes that hardware away from Unraid. Unraid has no way to know that this was unintentional. It is always a good idea to temporarily disable VMs anytime you do a significant change (hardware or OS) to avoid such issues until you have had a chance to check things out.

No rush as I should soon be ready to release an update that correctly handles your case.

... but I thought I remember reading it will be part of the OS at the 6.13 release?

Maybe something like this needs to be incorporated into the Dynamix File Manager?