itimpi

Definitely cancel it. You rarely want to be running a parity check if you think you have drives playing up.

The drives being disabled at this point is expected as nothing done so far would remove that state. Some questions to try and decide what is best as the next steps: The repair on the emulated disk2 seemed to complete without anything suggesting corruption being logged but Disk2 is showing as basically being empty - is this expected? Did you at any point try to format disk2? If so was this while it was disabled or before that? Do you have backups of what should be on disk2? Is the drive that should be in disk2 showing up under Unassigned Devices?

You are correct - I had a 'blind spot' when looking at the diagnostics, sorry about that Can you give some examples of the paths of files you think should go there. It is possible that your Split Level of 2 is constraining files to the other drives.

Even without the disk present you would be able to browse its contents if parity is valid as Unraid will try and 'emulate' it using the combination of the other drives plus parity. That is one of the reasons I asked if the drive had a red 'x' against it as if that is the case then Unraid would be ignoring the physical drive and any contents you see would be from the emulated drive.

Did you disable of the services - not just running instances while running mover? Keeping the services running will keep files open so that they then get ignored by mover.

The parity check is going to be meaningless if the disk has dropped offline Is disk1 still showing as present or has it got a red 'x' against it? I think the only way to know for certain is going to be if Unraid can emulate disk1 correctly if it is not in the system. I would wait for @JorgeB to get online as the best expert on these things to confirm but I think that is going to have to be the way forward. You definitely want to keep disk1 as intact as possible at this point in case it is needed for any recovery purposes. Do you have a spare drive you could use to replace it?

It all depends on whether you have valid parity - if you have then the answer is yes. Looking at the diagnostics it appears that disk1 may have dropped offline.

One suggestion is to try using Rufus to format the flash drive as that seems to have worked for some people. Are you trying to boot in legacy or UEFI mode? One BIOS setting that interferes with booting is having Fast Boot set, but if this is old hardware it is unlikely your BIOS has that option.

Any location that is not on a physical device would automatically be in RAM so you can get this already.

Not sure if you catch everything if logging to a share as this will stop as soon as Unraid starts unmounting any drives. You might get a bit more information if you are instead using the option to mirror to the flash drive , or if the syslog server is running on another machine.

Yes if using the option built into Unraid. If instead you use the plugin options to handle the increments and also set the option to restart array operations in the plugins then it can continue from point previously reached. However you need to resolve this reason you are getting unclean shutdowns as for safety reasons the plugin will not restart array operations after an unclean shutdown. I might one day think about revisiting this decision but I at the moment am erring on the side of safety.

If you are attempting to do a tidy shutdown then this tends to mean one of two things: The array is not stopping properly. You can try manually stopping the array before doing the shutdown to see if there are any issues in this area. Sometimes the shutdown timeouts need increasing as described in this section of the online documentation. The flash drive is having issues and Unraid is having problems writing back to the flash the fact that it has managed to stop the array successfully. To investigate this I would suggest enabling the syslog server to gets logs that survive the shutdown/reboot process. The logs that the plugin generates when the "Test" mode of log is active with the option to save the test log to flash might allow me to give you a indication about the second as well if it covers the shutdown and reboot process.

Looking at your share settings I am guessing that the share that is anonymizes as S-----------a is probably your main share by volume, and this share is set to NOT use disk9. It is normally recommended to only use the Include (or exclude) options on a share if you want to stop it using all drives so I you should probably leave that field blank on this share?

Big improvement, but still looks low for a gigabit lan.

It could just be a bad cable as 100 Mbps is less stringent than 1Gbps. A bad port is also a possibility but I would think less likely.

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

Your appdata, system and domains shares all have files on disk1 which explains why disk1 and parity disks are spinning up. These shares typically want to be held on a cache pool for performance reasons and if you are running the VM or Docker services they will hold files open (which stops mover transferring files).

The diagnostics no longer show AATA errors which is good. The SMART information shows (as you mentioned) that no test completed for that drive. When running such a test you want normal access disabled to avoid i aborting the test so best to do it without the array started or in maintenance mode. To do a thorough test you should run the Extended test but for that you often need to (temporarily at least) disable spindown for the drive while the test is running as it can take hours to complete. FYI: The diagnostics include the syslog and SMART information for all drives (plus other items) so normally no need to provide them separately.

As far as I know that simply means an error - why I have no idea. It could be a spurious one or it could be genuine - no way to tell. It is not unusual to have a small number of errors if there has been an unclean shutdown, It surprises me that in the screen shot you posted the type of check is not shown since you have the plugin installed. That suggest to me that it was OK at that address - if by any chance the previous check had been correcting that is what one would expect. Not had a lot of feedback from people using the Assistant so not really sure how definitive it is in the real world although it seems fine in my testing (but there I had to simulate errors rather than having hardware that might be throwing genuine errors).

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

Any drive that fails the Extended SMART test should be replaced. In addition having pending sectors (let along lots of them and the number increasing) is a bad thing as that would prejudice the error-free recovery of any other drive that failed. Neither of the above should be affected by cabling as they are internal to the drive. Power issues might cause problems but I doubt that is the issue - I would think it is the drive itself that is the problem.

The other one that I do not think is created automatically but is nearly always present is ‘appdata’ for the location where docker containers store their working set files. Although not crested automatically this will be the default set in many docker container templates. Most people also want this to be use Cache=Prefer but this is up to you.

You could try creating them directly on a physical drive rather than via the user share system to see if that works? I was thinking of something like mkdir /mnt/cache/domain assuming you have a pool called cache. Note that creating them this way would give them default values and for these shares you normally want Use Cache-Prefer for the domains and system shares to keep them on a pool for performance reasons/

I would suspect something that is common to all these drives. Things that occur to me is the power cabling and if they are attached to an HBA whether that is properly seated in the motherboard.

These default shares are only created automatically when you enable the Docker and VM services.