itimpi

If you do that you need to rebuild parity as parity1 uses a different algorithm to parity2.

Do not understand this bit. If you paused the parity sync it should not have completed until you logged in again and did a resume. Are you sure it actually paused?

Regardless of that setting, Unraid would not be deleting any files on the main server as that setting just controls whether they are visible over the network. If they did get deleted on the main server it was done by something else.

You can skip step 2 and do both step 1 and step 3 at the same time. This will then rebuild parity1 Your array is unprotected until that finishes so keep the old parity1 intact until that completes in case something goes wrong while rebuilding parity1. Note that once you have a valid parity1 you can reorder disks without affecting parity (would not have been true for parity2).. The way to proceed would be: Use Tools->New Config (i would recommend you use the option to preserve current assignments to reduce the chance of error). Go to Main tab and move all existing disks down a slot, and at the end leave disk1 slot empty Tick box that says parity is valid and start array to commit assignments. You can ignore a warning about parity being over-written as the check box stops that happening Stop array and assign old parity1 as disk1. Start array to commit this change. Unraid will start a 'Clear' on disk1 to avoid it affecting parity. When that completes you can format disk1 to make it ready for use.

Just shows how hard it is to generalise. My WD drives are the ones that die while the Seagates as the ones that seem to go on forever.

Have you followed the procedure that is documented here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. If you think the drive is fine you can rebuild it to itself.

Not sure there is a description of the sort you are asking for. The parity sync works serially through sectors starting on the outmost cylinders. As soon as the max sector on a drive has been used that drive has no further part in the parity sync. In your case the 2TB drive will be first to stop taking part and later the 6TB drive. The parity sync keeps going until the last sector on the parity drive (at 10TB) has been processed.

As far as I know Unraid does not support Secure Boot so it needs to be disabled at the BIOS level.

The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth enabling the syslog server to get a log that survives a reboot so we can see what happened prior to the reboot. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server’s address into the Remote Server field.

They could combine moving to a subscription model with honouring their earlier statements by having a "lifetime" subscription that is equivalent to the current licences and grandfathering existing users to that subscription. No idea if this is what is going to happen but I would personally be surprised if something like this does not happen. That would allow users in the future to choose between one large upfront payment and smaller re-occurring payments.

Alternatively you can delete (or rename) the .plg file for the plugin in the config/plugins folder on the flash drive and then reboot.

Simply enabling the syslog server put it into listening mode. To actually get something logged you had to either put your Unraid server address into the remote syslog server field or use the mirror to flash option (or both).

Do they appear under Unassigned Devices? Posting a screenshot and/or your system's diagnostics zip file might help us see what is happening. How are these drives connected? Can you see them in your system's BIOS?

That is why I think that Limetech may simply grandfather in existing users for new releases (effectively a "lifetime" subscription). That would avoid upsetting the current user base and start up a more regular revenue stream. Existing users would I think be happy with a subscription model for additional licences they may now want to purchase if the price is right. I guess we are going to have to wait and see though.

True. I notice that even with the "embedded" messages posted it looks like they are tying any subscription to new releases so those happy to stay on their current release are OK. Having said that if the prices are reasonable (e.g. something like $10 per year or similar) I would think most current users would be happy to pay both to get new functionality and to get fixes to current functionality. Giving Limetech a regular income stream seems a good way to mean that we continue to get new functionality and fixes. I do notice that the web site still says current licences are valid for future releases so maybe they will simply grandfather in current users for future releases.

Even if Limetech switch to a subscription model for "New" licences I would be surprised if they do not honour the "Lifetime" current licences. A subscription model would allow for a much lower price entry point for new users which is something that has been that has been requested for some time. Note that is just my view - I have no insider information.

Yes. This is what is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom.

I would not bother unless you have problems with docker containers which are incorrectly configured and exhibit the symptoms this plugin helps hide.

Shame as that was the easiest thing to try. First time I have heard of this issue so grasping at straws for suggestions and nothing stood out in the diagnostics. Have you tried booting in Safe mode? If that works then it would identify that a plugin is the cause. If that works my first guess at a likely culprit would be theme engine plugin.

The automated licence transfer process requires internet access. Suspect it may not be needed if you contact support to get it transferred but not had to do it myself so may be wrong about that.

I do not believe you can transfer a Trial key to a different flash drive. I think instead you need to get a new Trial key for the new flash drive.

Not necessarily - it can be just the case that when all of them are plugged in the motherboard controller cannot handle the load of the total throughput required. This is one of the reasons many motherboards quote a smaller maximum RAM clock speed if all RAM slots are populated. Have you checked both the motherboard manual and the CPU spec to see if either of these imposes such a limit?

If you are talking about the "read SMART" entries in the syslog I do not think it is these spinning up the drives. They are done by the system just after detecting a drive that was spun down has been spun up because something accessed the drive. You need to identify what is accessing the drive to cause the spinup. The File Activity plugin might give you a clue.

Have you rebooted your system? If so you should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

Do you even have empty folders corresponding to those shares as that will trigger the warning. you can use the Compute All button on the Shares tab to see which drives have content for any particular share.