itimpi

That looks good - if you now stop the array and start it in normal mode the disk should now mount. You should now look to see if you have a lost+found folder on the disk as that is where the repair process puts any files/folders for which it cannot locate the directory information giving the name.

That is expected since the command you used was not quite correct.

You should now try without the -n option.

How did you try the repair (i.e. via the GUI or via the command line)? If the latter what was the exact command you used.?

The command you used is wrong as you need to add the partition number (/dev/sdo1) if using the sd device.

You only get updates at 10% intervals and it normally takes something along the lines of 1.5 hours per TB.

If you move the flash drive at the same time then the new build should 'just work' once the drives are plugged in. The Unraid licence and all settings move with the flash drive. The only caveat is if you have drives attached on either build via a RAID controller then more might be required. This is because Unraid recognises drives via their serial numbers and RAID controllers may not pas these through unchanged.

The flash drive is mounted under /boot and that is where you should look for the ‘logs’ folder.

This is a bit strange - I would always expect the mitigations to reduce performance.

Not so as it always downloads as a zip file. It will be the fact that your machine has automatically opened the zip file and shown you its contents (not at all unusual on MacOS). You should be able to find the downloaded zip file on your machine.

Since no data drive can be larger than the smallest parity drive you will need to use the Parity Swap procedure. I suspect that you will have to do it twice, once for each failed data drive (but I may be wrong about that and you can do two at the same time, something I have never tried myself). a point to check - are you sure the disabled disk are really faulty? Drives often get disabled due to external factors rather than the drives themselves failing. If you post your system’s diagnostics zip file we might be able to give you some feedback on that.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

That disk looks very sick and definitely needs replacing ASAP

Not quite. If the cache pool fills up then NEW files overflow to the array (and are later moved to the cache if space becomes available). Files already on the cache are left there.

You definitely have an issue with the flash drive as you are getting error messages such as: Oct 9 13:20:31 unRAID kernel: FAT-fs (sda1): Directory bread(block 32768) failed Oct 9 13:20:31 unRAID kernel: FAT-fs (sda1): Directory bread(block 32769) failed and other ones that indicate failures trying to access files under /boot (which is where the flash drive is mounted). Could not tell whether the problem was the flash drive itself or something else that was causing it to go offline.

No, unfortunately that will not work. That option is only about automatically pausing/resuming a running operation, not about restarting it from the point reached after a reboot or array start/stop which is what you want.

Do you by any chance have an ad blocker installed in your browser? If so you need to white-list your Unraid server as an ad blocker can stop the Unraid GUI functioning correctly.

This sounds more like a problem of some sort at the hardware level. The requested diagnostics should allow for more informed feedback.

I’ve checked the code and at the moment it only allows for resuming a parity check from the last position reached after a reboot or array stop/start. I will need do some investigation to see whether the plugin can be enhanced to allow a similar capability to be extended to drive rebuilds and/or parity syncs (builds) .

Unraid does not care where drives are physically connected. It simply recognises drives using their serial numbers.

As long as both HBAs report the serial numbers of the drives in the same way then the swap will ‘just work’.

Docker containers have the software they use installed internally to the container. If there is a problem with the PHP version then it is a container issue and nothing to do with Unraid.

Have you made sure you exported the share to make it visible on the network?

If you are having problems with the USB Creator tool then you can try using the older Manual install method documented 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 SMART information for the drive shows nothing obvious, although you might want to consider running an extended SMART rest on the drive to make sure. A drive is only disabled if a write to it has failed for some reason. The disabled state will only be cleared by rebuilding the drive contents. If you want to do this to the same drive then the process to use is covered 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. At the moment Unraid is emulating the emulated drive using the combination of the other array drives plus parity. Before doing a rebuild you should check that the contents of the emulated drive contents look like what you expect as the rebuild process simply make a physical drive match the emulated one.