itimpi

Q1: As far as Unraid was concerned there WAS a problem. Q2: Do NOT format unless you want to lose the drives contents. A format creates an empty file system on the drive (currently being emulated) and updates parity accordingly. A rebuild always puts onto the drive exactly what you see on the emulated drive and is NOT preceded by a format. Q3: Not sure about the best way to handle this. Are you certain that nothing has been written to the array since the drive played up?

You will have to do a rebuild to get the drive out of a disabled state. You can use the procedure documented here in the online documentation (accessed via the Manual option at the bottom of the Unraid GUI) to rebuild onto the same drive.

This section of the online documentation (accessed via the ‘Manual’ link at the bottom of the Unraid GUI) covers rebuilding a disk onto itself. You may also find the preceding paragraphs to be of interest.

You mention having a ‘parity’ disk and separately mention a 10TB disk. Are these the same or do you have another 10TB disk to use as parity? It is a requirement that any parity disks be at least as large as the largest data disk in the array. all drives need to be formatted by Unraid before they can be used in the array. Prior to formatting a drive (which wipes any existing content) you will need to set whether it is going to use an encrypted file system or not. Therefore the NTFS disks cannot be used ‘as-is’, although they CAN be mounted as Unassigned Devices for purposes of copying the data off them. I prefer unencrypted drives as encrypted drives can be hard to recover their contents if anything happens to go wrong, but that is a personal preference. You have to decide yourself on how to balance privacy v convenience. parity and cache can be added at any point. It is commonly recommended to not use cache during initial data load. The recommendation to not use parity during this stage is a trade-off of speed v protection. Copying without parity is faster but your data is not protected against drive failure until parity has been built. regarding pre-clear, you may find this section of the online documentation useful in clarifying its use.

You can safely update the plugin at any point without problems. The vast majority of the time the plugin is actually inactive and even if you did the upgrade at the exact instance it was going to attempt a pause or resume the worst that could happen would be for that particular pause/resume to not take effect.

Are you running the 6.9.0 beta? Multi-language support (and thus Chinese support) is new in the 6.9.0 release and not available in the 6.8.3 release.

if you use the 6.9.0 beta release it includes drivers for 2.5Gb NIC. The 6.8.3 release is based on an older Linux kernel and does not include the required driver.

FYI: If the parity check tuning plugin is installed then it will add to the history whether it was a correcting or non-correcting check. It will not change the message you mention that is displayed at the end of the check, but it can still be useful to be able to look this up.

I have been able to reproduce this. Looking at the underlying configuration file it IS being changed despite the settings page saying it is enabled., so this may be just a display issue. I will need to work out why this is happening and issue a fix. EDIT: The value in the GUI is (incorrectly) displaying the setting associated with the "Pause and Resume array operations if disks overheat" setting. I can confirm, however, that changing the setting and hitting Apply DOES change the stored setting.

You are probably falling foul of the fact that preclear is not a standard part of Unraid but a 3rd party utility so the GUI does not take account of the fact that a Clear had been done outside the control of Unraid.

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.