itimpi

Update: Fix Debug logging being active even when set to be disabled. Fix default (for existing plugin users) of new Shutdown option defaulting to enabled when it should be disabled.

I can confirm that debug level logging is active when it should not be. There is another buglet where for existing users of the plugin the default for the new Shutdown option is to have it enabled rather than disabled (it is correct for new users) so you might want to check this out as that logging actually shows it is active and you may not have intended this? I will get both of these issues addressed and an update issued later today.

I thought it did (and was certainly meant to). I’ll check this out as you are almost certainly right if it did not default correctly for you.

It looks as if disk2 has dropped offline (so there is no SMART information for that dtive in the diagnostics) and in that case no point in trying to continue rebuild of disk3. Doing a power cycle on the server may be required to bring it back online. As always you want to check the SATA/power cabling to the drive. New diagnostics after the reboot should allow us to check that it looks OK.

This is covered here in the online documentation that you can access via the 'Manual' link at the bottom of the Unraid GUI.

You need to give more information about the problems you are getting and the commands you think you have to run. Most people can shutdown their server without problems as long as the hardware is not mis-behaving.

You would be able to do preclears OK. You will not be able to use VMs or dockers as the supporting services are not started until the array is started.

I guess that might make it happen as that would create the folder. The yellow status is triggered by there being a folder corresponding to the share name. The system does not look inside the folder to check its contents.

I think the point is that if you were doing things over the network then this situation would never arise so is has not been catered for (perhaps for efficiency reasons).

I cannot replicate this. The only way I got the symptoms you describe is if I deleted the file but not the folder on the cache drive that corresponded to the share name. Running mover then removed this (empty) folder and the status went back to green.

It should auto correct. The fact it has not suggests you still have a file or folder in the wrong location. Did you remember so also delete the containing folder and not just the file? You should be able to find the culprit by going to the Shares tab in the GUI and click the 'folder' location against the share. That will show which files/folders are on which drive - and you can drill down if required to find the culprit.

This is why it has not worked You have encountered a side-effect of the way the mv command operates under Linux. It first tries to do a simple rename (which is fast) and only if that fails does a copy/delete operation. In this case the rename has worked (the Linux level is not aware of user shares) so it has stayed on the drive. To avoid this happening you need to either do an explicit copy/delete or set the target share to Use Cache=Yes so that mover later moves the file to the array. You would not have encountered this issue if you had done it over the network rather than internally within the server.

I must admit I could not spot anything in the diagnostics to explain what happened Except that as far as parity is concerned the answer is 0

Unraid is quite happy to boot without a GPU as long as the motherboard BIOS will let it do so. Many users run their Unraid systems headless and in fact until v6 this was the only way to run Unraid.

The file should not exist if it has really been deleted as that happens in real time. how did you check that the file does not exist in the share? It should show up if you view it via the GUI if it is on the disk as the share is simply an alternative view of the disk contents. I think you are going to have to manually delete the file, but it seems a good idea to try and work out why this happened in the first place. The fact you were building parity at the same time should be irrelevant (except for the performance hit it introduces). Parity is not aware of files (or file systems) as it works purely at the disk sector level. No idea if it will help but posting your system diagnostics zip file (obtained via Tools->Diagnostics) might be worthwhile to see if anyone can spot something.