itimpi

The release I have just made should fix the parity history reporting issue. Please let me know if it does not.

The release I have pushed should correct your issue. Please let me know if you find that it does not.

A small point of semantics, but I would remove the word ‘Enable’ from the setting description as to me that combined with the ‘No’ setting implies no security is applied which is not the case.

Have you checked under Settings->Unassigned Devices that the SMB Security is not set to No (the default nowadays) as that will stop all UD managed devices being visible via SMB regardless of the settings on a particular device.

I think such a project would be a huge undertaking. After all there are those who make a living out of providing utilities (such as UFS Explorer on Windows) that can do this.

A point to bear in mind is that if memtest fails you DEFINITELY have a problem, but a pass is less prescriptive meaning you PROBABLY do not have a problem,.

No checkbox needed as Unraid will recognise drives that have been used by Unraid and already have data on them and will simply add them untouched. In fact you have to take additional action (e.g. reformat) on them to get them reset to an empty file system.

I would suggest that you look in /var/log to see what is taking up most of the space. It does not appear to be the standard syslog. Using the following commands from a console window will probably make it obvious: ls -l /var/log du -sh /var/log/*

Are the machines you want to try Intel/x86 based as this is a requirement for running Unraid

Do not need to enable increments if you do not want to. I have confirmed that the plugin will fail to resume if no increments enabled, and I have already worked out the fix to test.

Unfortunately not as part of tightening security a password is now mandatory. the only way to achieve what you want would be to set up a separate web server (probably in a docker container) and go via that.

Yes. Parity1 does not care about slot number whereas parity2 does. It is safer to assume both parity drives are invalid and create new parity.

You can do most of that by recreating the USB stick (keeping just the licence key). You would, however, need need to reformat any drives after adding them to Unraid to clear any existing data after first starting the array but that is easy enough to do.

Looks like it a plugin bug that I will have to fix rather than the Unraid release I did not think anything had changed in the code in the area affected but I must have been wrong. If you look in the parity-checks.log file (it is a text file) then you will see that the last line has an empty field that on the other entries is set to "check P". This entry is generated by the plugin so I need to work out why that field was not populated as according to the progress.save file you sent it should have been. As a temporary fix you can add the missing field to the parity-checks.log entry and it will then display the history entry as expected.

Looking at the diagnostics it looks like you have no array operation type scheduled to run in increments (please confirm this), and I think there is a bug in the plugin that in that scenario the plugin is not correctly resuming the check after mover or ca.backup operations finish. I will look into rectifying that.

You may find this part of the documentation useful in at least identifying which are data and which are parity drives.

The behaviour you describe sounds correct for the way that you have your system is currently set up. You are trying to overload your pool capabilities. A point to remember is that Minimum Free Space does NOT mean keep that amount of space free. It is a value that when it drops below that the NEXT file to be created is sent to a different drive. The current file will continue until it is complete which can take the free space well below the setting value.. That is why you want that setting to be larger than the biggest file you want to transfer. Mover will not automatically move files off to get to the Minimum Free Space value. It does not make sense to have Use Cache=Prefer for shares which total more than the available space. You should either restrict this setting to those shares you really want on the pool and that will fit, or alternatively you can increase the size of the pool, or create additional pools. Many people will have separate pools for caching, docker apps, VMs etc with each one using hardware and settings optimised for that type of use although there is nothings stopping you combining these functions onto a single pool.

The issue you have to contend with is that the moment you move disks between slots this will invalidate parity2, Parity1 does not care about slot number. The procedure I would recommend is: If you have not done one recently do a parity check to ensure that parity is currently valid and no drives have issues. Use Tools->New Config and select the option to retain all current assignments Return to the Main tab and unassign parity2 Set the data drive assignments as you want them to end up Click the Parity is Valid checkbox and start the array to commit the drive changes. Ignore any message that suggests parity will be overwritten as it does not take into account the checkbox being ticked. At this point the array should now be operational with all the data intact and parity1 in place for protection. If you have any shares that were including or excluding a drive whose position you have changed the settings will need amending appropriately. Stop the array Assign parity2 Start the array to rebuild parity2 based on your revised drive assignments. This is likely to be the most lengthy step.

None of the plugins listed are known to have a problem. You could try rebooting in Safe Mode which avoids loading all plugins to see if that helps. Is your server directly exposed to the internet in any way? You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

Cannot think of any recent change in the plugin that should have that result (famous last words ). Could you perhaps post (or PM me) the following files from the flash drive: /config/parity-checks.log /config/plugins/parity.check.tuning/parity.check.tuning.progress.save If you still have diagnostics covering the period when the check took place then the syslog might just be relevant although I think the above two files should allow me to see where the issue might be. Also, what release of Unraid are you running?

When you start the array in normal mode that drive should now mount OK.

Have you made sure that both vlans have gateways set so that there is appropriate routing between the vlans?

Unless you have been really unlucky with the 2 SSDs I would suspect somethings wrong at the hardware level.

I think you may be right, but I do not bother with flash drives that large as it seems a waste of space so not tried it myself either. Plenty of 3rd party utilities around that can do this anyway.

I notice that this plugin says in the Status Line of the GUI that it is creating a swap file even when I start the array in Maintenance mode. Is it really trying to do this (which it should not) or is the message misleading?