itimpi

I would think so, but you are welcome to try a soft reboot to see if they come back online but do not be surprised if they do not.. After doing that then the diagnostics might give a clue as to the drive state as they may then have SATA information for the problem drives. You could also try doing an extended SMART test on the 2 drives, if they passes without error I would be looking into the power/sata cabling as possible culprits.

You are getting errors on both the parity disk and disk2. As suspected it definitely looks like they both dropped offline.

The syslog included in the diagnostics only shows what has happened since the reboot as it resets every time the system is booted. You need to enable the syslog server to get logs that survive a reboot.

Unfortunately I cannot see anything in that log that gives a hint as to what the problem might be.

It is always easy to manually downgrade (or upgrade) using the manual method described here in 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.

The syslog provided earlier is just the RAM copy that is included in the diagnostics zip file and just shows what happened since the last boot. I suggest that you enable the syslog server to try and get a syslog that can survive a reboot.

Not sure if it will help, but in the commands need the X in the sdX to be replaced by the letter that is actually relevant to your system.

I would suggest that you update to the current stable release (6.12.3 with 6.12.4 coming soon) to see if the problem still exists.

This is unlikely to find the issue. Have you changed any drives recently?

Have you tried rebooting since changing the drive to see if the problem then corrects itself?

Your symptoms suggest that the drives in question have dropped offline. It is probably going to take at least a reboot to correct this, and possibly even a complete power cycle of the server. It is possible your system's diagnostics zip file may give more information.

Are you sure you do not have any power related issues (either PSU or cabling to it). The parity build/check are times when it is likely to be under maximum stress.

I think that means that the Manual method may still work. I personally never use the USB Creator tool so I am not certain.

This is a feature that is meant to be coming in a future release although I have no idea of the timescales. There were changes made in the 6.12.x releases to start getting ready for this. This is likely to happen in the same timescale as the above feature. In the 6.13 release we have been told that the aim is to make the current Unraid 'array' just another pool type and then you can have any mix of pool types (including multiple Unraid 'arrays' if you want. However having said that until it actually happens we cannot be certain when it will happen or if Limetech will deem some other mix of features to be higher priority.

If it is simply not working rather than telling you that the flash drive does not have a unique GUID then try using the Manual Install method that is far more reliable than the USB Creator tool which seems to fail on some systems for no obvious reason.

I would expect it is most likely to be a mapping in a container that needs fixing.

What is actually held on disk4? I am assuming it is there for a good reason?

It is being started by an amended config/go file on the flash drive: yours reads #!/bin/bash # Start the Management Utility tor /usr/local/sbin/emhttp & /bin/bash /boot/config/wireguard/go while the standard default one issued with Unraid only contains #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & if there are any files in the ‘extras’ folder on the flash drive they should also be removed. More concerning is how a bad actor gained access to your server in the first place to make these changes. Do you have your server exposed to the internet?

The idea of the syslog server is that any machine can send entries to it via the network, it does not generate the entries on its own. The idea of the last two entries is to provide a way to capture syslog entries generated on the host machine.

You can deactivate a plugin by renaming its .plg file in the config/plugins folder on the flash drive to have a different file extension and rebooting. Reversing the process will activate the plugin again. This method keeps any settings for the -login intact. It is then a case of trial and error to work out the culprit(s).

With those settings nothing is going to be recorded as those settings just set up the server to be listening. There are 2 ways to get something recorded: use the Mirror to Flash option (normally the easiest). In this case the results are put into the ‘logs’ folder on the flash drive.. put the IP address of the Unraid server into the Remote syslog server setting. In this case the results are put into folder specified in the settings.

If you get the GUI showing if you boot in Safe Mode then this strongly suggests that it is a plugin that is causing the problem. I do not know which one it might be

Glad to hear it was the issue. Originally this only seemed to happen on shucked WD drives, but it seems that other manufacturers/models can experience this issue.

it appears you no longer have a pool called ‘cache’ so any docker mapped to a path that starts with /mnt/cache is writing/reading from a RAM location. You need to change any mappings to be mapped to a path that is valid in your current setup.

There is 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 that can help with sorting out drives if necessary.