New node - disqualified

Node Operators troubleshooting
1

I’m having this strange issue. Old node died because of the hard disk failure. I’ve replaced the disk, took a new identity restarted the node (same IP, same port). But it did not started. For some reason i’ve got error saying, that node is disqualified.
I tough that i somehow messed up with certificates/identities.
Restarted once again, with new identity. But got the same issue. I’m 100% sure that this is new identity.
By the way, in the dashboard i see that this node (that i’ve started 2 days ago), earned 3$ and 5$ are held. It’s for sure some old information. But how this is possible?

By the way on the same IP i do have another 3 nodes and they are running just fine.

Any ideas what is going on?

Thank you.

2

did you deleted old databases?

3

This is what killed your node. You can’t mix files and identities.

Delete everything, start from scratch.

1 Like
4

Did you authorize the new identity with a new authorization token also? Because they are single use only and you have to go through the complete setup process like it was a new node.

2 Likes
5

Sound like you took a new authorization token instead of wiping the old identity and generate a new one.

The same identity even signed with a new authorization token is still the same identity, with lost data and still disqualified.

this is doesn’t matter. If the identity is the same it will remain disqualified despite number of authorization tokens applied to it.
They must delete the old identity and generate a new one.
Also there is a proposal to remove the authorization requirement, I believe that it’s already implemented.
So only what they need to start a new node is to generate a new identity.
Please let me know, does it allow to join the network with the unsigned identity.

6

But he said:

I might be wrong but to me this sounds like he has used a new identity but maybe he means the auth token?

What does this mean? No more authorization required only untar and use without signing it?

7

of course! Since 1st dead i’ve reaplaced hard drive.
Since 2nd dead i’ve reformatted drive.

8

I haven’t! It’s obvious!
That’s why i’m confused!

9

yes! i always do it!

10

When creating a node, i always make a note for my self. I write down when the node is started, what it’s ID, and what it’s identity. Like: “identity.1664746174”.
And i clearly see, that the number is different.

11

I’m with storj for a long time. I never did such a “basic” mistakes like starting a new node with the old identity. It’s obvious. That’s why i’m so surprised.
I do have library of ready made/prepared identities. Just in the case i need. So all these identities where generated/signed like ±1 or 2 years ago. But i never had any issues with it. If the drive fails, i just pick up next identity with certs, and restart the node.
It is extremely strange.

12

Yes, this is the goal. The authorization requirement was needed when we started, but now it’s just a rudiment.

13

The number, which you noted is a date in a UNIX format, so it’s irrelevant.
For now it looks like you reused the old disqualified identity (or some which was alive until now). So, please, just delete it and generate a new one.

14

So are the docs outdated then?

Authorize your Storage Node identity using your single-use authorization token (please, replace the placeholder email:characterstring to your actual authorization token):

Confirm the identity
Run the following command to confirm you have the required identity files:
The first command should return 2 , and the second command should return 3 :

So this is obsolete and only untar identity and use it is required?

15

Perhaps. Until the engineering team would say, that’s outdated, we will keep this doc. Especially while this auth tokens generator is still alive.