Your node has been disqualified - What are these bugs?

What caused it when I launched a new 16 TB HDD.


Hi @coinbirds - is this a brand new node or did you transfer data from an old HD to a new one? Also what is your node ID?

Hi @jennifer

Brand NEW node
Node ID: 12Qcyq9t2bRonGZdXkLZfU8wx4m9A6BXZryT9vrvcNv2WbiaAmh

Hello @coinbirds ,
Welcome to the forum!

Please, check your logs for reasons:

It’s important, because you of course can generate a new identity, sign it with a new authorization token and start with a clean storage, but the next node could fail for the same reason.

If this was a second node with the same identity as a first one - both will be disqualified for missed data from another disk. Each node must have an own unique generated identity (only using a different authorization token is not enough).

Thanks for the reply.
Yes, this is the second NODE with the same identity.

I deleted the first one due to an error.

“022-02-11T08:51:14.173+0100 ERROR servers unexpected shutdown of a runner {“name”: “server”, “error”: “read udp [::]:28967: wsarecvfrom: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself.”, “errorVerbose”: “read udp [::]:28967: wsarecvfrom: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself.\n\tstorj.io/drpc/drpcserver.(*Server).Serve:107\n\tstorj.io/storj/private/server.(*Server).Run.func5:227\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57”}
2022-02-11T08:51:14.190+0100 FATAL Unrecoverable error {“error”: “read udp [::]:28967: wsarecvfrom: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself.”, “errorVerbose”: “read udp [::]:28967: wsarecvfrom: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself.\n\tstorj.io/drpc/drpcserver.(*Server).Serve:107\n\tstorj.io/storj/private/server.(*Server).Run.func5:227\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57”}”

It was only active for 2 days so it was easier to do a new node
Since I couldn’t solve the problem I deleted everything and I created a new node with the same “Auth Token”.

What is the solution?
Do I need to delete everything and create a new “Auth Token”?
Do you need a new email address for this?

Thanks in advance

Each node must have an own unique generated identity. So for two nodes you need to create two identities following this guide: Identity | Node Docs
To make it different I would suggest to run each one with own name. For example, the first one can be as described in the guide, i.e.

identity create storagenode

The second one then should be generated with a new name:

identity create storagenode2

Then you need to sign both with own Authorization Token | Node Docs.
For the first one

identity authorize storagenode your@email:1Ghhfjhrokleurfhjidjrijfk...

for the second:

identity authorize storagenode2 your@email:2rektmtuhcdyrRRFmdjn...

The name of the service here (storagenode and storagenode2) is just a folder in the default path.
For Windows %APPDATA%\Storj\Identity\storagenode and %APPDATA%\Storj\Identity\storagenode2 accordingly.

However, I would not recommend to start the second node until the first one would be at least vetted.
We filter out nodes by /24 subnet of public IPs, so they start to act as a one big node for uploads and as a separate ones for customers’ downloads, audits and uptime checks.

Each new node must be vetted. Unvetted node can receive only 5% of customers’ uploads until got vetted. To be vetted on one satellite the node should pass 100 audits from it.
For the one node in the same /24 subnet of public IPs it should take at least a month.

For the several unvetted nodes in the same /24 subnet of public IPs the vetting period could be in the same amount of times longer as a number of unvetted nodes.
So, I would recommend to start the next one only when the first one almost full or at least vetted.

3 Likes