"Fix common problems" plugin started throwing out this warning a little while ago.

 

Multiple registration keys found

 

While unRaid will operate with multiple .key (registration files) within the config folder on the flash drive (ie: For simplicity sake you have multiple valid registrations and are storing them all within the config folder, you will run into problems if you ever need to transfer one of the registrations to another USB stick, as unRaid will not know which registration file to transfer, and the incorrect registration may get blacklisted. You should investigate and determine which key belongs to which USB stick and only have that particular key on that stick

 

I have a unraid with unraid plus license (12 drive one). My unraid installation was originally with 6.1.x (about a year back) and has been auto updating since (6.2.4 at the moment). Unsure if this is an actual issue, and how to go about fixing it? Why would this have happened anyway (if its actually an issue).

If you have not have one valid license why not simply remove the redundant key file from the USB drive (make sure you pick the right one - if not sure rename it by changing the file extension)?  There must be some reason why more than one is present - do you have any idea why this happened?

unRAID will start fine with multiple keys on the flash. It just searches until it finds the one that matches. The problem comes when you need to get a key replaced. The automatic key replacement can blacklist the wrong flash drive because its key is on the new key. See here

If you have not have one valid license why not simply remove the redundant key file from the USB drive (make sure you pick the right one - if not sure rename it by changing the file extension)?  There must be some reason why more than one is present - do you have any idea why this happened?

 

I ended up with two key files when I upgraded from a trial key to a permanent one. It must be a very common thing since people are encouraged to try before they buy. I should think that any upgrade (such as from Plus to Pro) would result in the old key being left behind too.

 

Ah I see. I upgraded from trial too.

 

This is silly. Does unraid developers want people's flash drives to be blacklisted? I hope someone sees this and fixes it. If it wasn't for fix common problems plugin, I wouldn't have even know. How was I suppose to know how many key files are there, or where they are even located?

 

Sigh...

 

Sent from my Nexus 6P using Tapatalk

 

 

Ah I see. I upgraded from trial too.

 

This is silly. Does unraid developers want people's flash drives to be blacklisted? I hope someone sees this and fixes it. If it wasn't for fix common problems plugin, I wouldn't have even know. How was I suppose to know how many key files are there, or where they are even located?

 

Sigh...

 

Sent from my Nexus 6P using Tapatalk

LT is aware of the problem.  By and large if you only have a single registered key, then there is no problem.  *Technically*, there is no problem even having the trial key and a pro key on the same stick except in a certain circumstance.

 

And yes it is a very common thing and I got confirmation from LT today on my question as to whether or not this would affect users who've upgraded from Trial.  And it is possible for an issue to occur (but unlikely).  And since it's unlikely to occur except pretty much in the case of multiple registrations, they probably didn't consider it.  (nor have they really ever advocated keeping multiple registered keys on a single stick)

 

But since I cannot tell if there are multiple registrations, as far as I'm concerned the test returns an appropriate action (delete the key that's not being used) even if the odds are that it won't affect you.  Better safe than sorry.

 

Perhaps the key upgrade process ought simply to rename the key that it supersedes.

 

Perhaps the key upgrade process ought simply to rename the key that it supersedes.

Or delete it...  Either way it solves the edge case scenario.

Oh and to clarify, your quote:

 

 

Does unraid developers want people's flash drives to be blacklisted?

Blacklisting a flash drive is always going to be part of the key replacement procedure.  Rightfully so.  The issue here is blacklisting an incorrect flashdrive.

Can someone clarify/help how to find these duplicate keys and how to go about deleting them?

 

I had a look at the server, at "/boot/config", i see to files with ".key" extension. They were, Trial.key and Plus.key. Is this the right location i should be looking at? Should i be deleting/renaming the "Trial.key" file?

 

Cheers.

Can someone clarify/help how to find these duplicate keys and how to go about deleting them?

 

I had a look at the server, at "/boot/config", i see to files with ".key" extension. They were, Trial.key and Plus.key. Is this the right location i should be looking at? Should i be deleting/renaming the "Trial.key" file?

 

Cheers.

 

Yes, you should simply delete the Trial.key file.

 

The issue you were warned about by the "Common Problems" utility is really NOT an issue at all if all of the keys are for the flash drive you're using -- e.g. if you had a Trial.key,  Plus.key,  and Pro.key on the same drive that were created as you upgraded from Trial to Plus to Pro.

 

When it's an issue is if you have multiple keys for DIFFERENT flash drives all stored on the same drive.    Some folks apparently just store all of their keys on every drive they have -- knowing that UnRAID will still boot fine since it will search for a .key that matches the GUID of the flash drive and use that.

 

The issue would happen if you did this:

 

(a)  Copied the contents of an "old" flash drive to a new flash drive  (perhaps copying it all from a backup of the drive after it's failed)

 

(b)  Booting with your new flash drive, and then invoking the "Replace key" process -- which will register your new flash drive's GUID  AND  will invalidate the GUID for the old flash drive.    If, for example, there are multiple Pro keys stored on the flash drive, then it simply replaces the first one it finds -- which may NOT be the correct GUID for the old flash drive ... i.e. it might correspond to one of your other licenses.      And Voila -- the next time you try to upgrade the system with the now-invalidated GUID it will stop working.

 

Note this isn't an issue at all if all the keys are for the same flash drive -- since clearly the correct GUID would be invalidated if you did a key replacement.    So although you can simply delete the "lesser" keys in that case, it really is not a problem.

 

Note this isn't an issue at all if all the keys are for the same flash drive -- since clearly the correct GUID would be invalidated if you did a key replacement.    So although you can simply delete the "lesser" keys in that case, it really is not a problem.

 

Perhaps FCP ought either to ignore this false positive or else offer to delete the lesser keys.

 

Note this isn't an issue at all if all the keys are for the same flash drive -- since clearly the correct GUID would be invalidated if you did a key replacement.    So although you can simply delete the "lesser" keys in that case, it really is not a problem.

 

Perhaps FCP ought either to ignore this false positive or else offer to delete the lesser keys.

As I stated a couple of posts above because of the possibility that this can still mess up and I cannot tell how many keys are registered as far as I am concerned FCP is erring on the side of caution (which is true of many of its tests) and I believe the error should stand.  I will however modify the text associated with it.

 

Once LT adjusts their transfer key process then the tests will be removed altogether

 

 

And I cannot merely delete the trial key because it is also possible the the basic / pro key present is actually invalid and the user is running on the trial key

Sent from my LG-D852 using Tapatalk

 

One very simple reason FCP can't delete the extra keys is that the keys are encrypted -- so it's not easy to tell what GUID a key is tied to.

 

 

One very simple reason FCP can't delete the extra keys is that the keys are encrypted -- so it's not easy to tell what GUID a key is tied to.

 

The keys stored on the USB device are public keys. Surely checking such a key against a known GUID is easy. It's the creation of such a key that is intentionally difficult (in the sense that it needs access to a private key that LT's server keeps secret).

 

One very simple reason FCP can't delete the extra keys is that the keys are encrypted -- so it's not easy to tell what GUID a key is tied to.

 

The keys stored on the USB device are public keys. Surely checking such a key against a known GUID is easy. It's the creation of such a key that is intentionally difficult (in the sense that it needs access to a private key that LT's server keeps secret).

 

I don't think so -- take a look at your key files.  (Open one in Notepad)

 

One very simple reason FCP can't delete the extra keys is that the keys are encrypted -- so it's not easy to tell what GUID a key is tied to.

 

The keys stored on the USB device are public keys. Surely checking such a key against a known GUID is easy. It's the creation of such a key that is intentionally difficult (in the sense that it needs access to a private key that LT's server keeps secret).

 

I don't think so -- take a look at your key files.  (Open one in Notepad)

Sounded kind of backwards to me. Public keys are used to encrypt things that can only be decrypted by the private key. In any case I assume Squid has neither the public nor the private key to work with the encrypted files that we are calling the license "key".