Trying to setup a storage node on a raspberry pi - node disqualified


After setting up a raspberry pi 3 with a 2TB USB drive following the instructions on “Install storagenode on Raspberry Pi3 or higher – Storj”, I have got an error:
2021-04-16T13:24:17.903Z INFO failed to sufficiently increase receive buffer size (was: 176 kiB, wanted: 2048 kiB, got: 352 kiB)
Which I remedy adding net.core.rmem_max=2500000 to sysctl.conf.
But now after restarting the node I see no more errors on the log but unfortunately I still see the node disqualified error on the web interface.
Should I wait to see if it resolves itself with time?
Node is online, version is v1.25.2

current logs are:
2021-04-16T13:28:38.142Z INFO Configuration loaded {“Location”: “/app/config/config.yaml”}
2021-04-16T13:28:38.170Z INFO Operator email {“Address”: “”}
2021-04-16T13:28:38.171Z INFO Operator wallet {“Address”: “0xd25014695496222ca9bd6f078851B1366e8f71Ac”}
2021-04-16T13:28:39.885Z INFO Telemetry enabled {“instance ID”: “1pCN34y6arUAnD8WHG8NCzc9YtWciHsZcWcmv2GMsMHGq8xU7c”}
2021-04-16T13:28:40.130Z INFO db.migration Database Version {“version”: 51}
2021-04-16T13:28:43.047Z INFO preflight:localtime start checking local system clock with trusted satellites’ system clock.
2021-04-16T13:28:44.189Z INFO preflight:localtime local system clock is in sync with trusted satellites’ system clock.
2021-04-16T13:28:44.190Z INFO bandwidth Performing bandwidth usage rollups
2021-04-16T13:28:44.191Z INFO Node 1pCN34y6arUAnD8WHG8NCzc9YtWciHsZcWcmv2GMsMHGq8xU7c started
2021-04-16T13:28:44.192Z INFO Public server started on [::]:28967
2021-04-16T13:28:44.196Z INFO Private server started on
2021-04-16T13:28:44.194Z INFO trust Scheduling next refresh {“after”: “5h0m56.559372545s”}

Best regards

Search your log for failed and GET_AUDIT in the same line.

Hi @nerdatwork, thank you for your help, I don’t see any of these messages on the log right now but on the web interface I see that my node was disqualified several days ago when I first tried setting the node at home but at the time I was unable to forward ports, now I am on a new internet connection with the ports forwarded and the node is online but the error persists, maybe the satellites have outdated information about my node, I will wait for a refresh

1 Like

I’m pretty sure you can’t come back from being disqualified.
If the node is new I suspect you may as well spool up a completely new one.

Hi @ACarneiro, I see, so the status disqualified is a dead end, will try to spin up a new one and post the results here, thank you.

Disqualification is permanent. You do have to check, why your node failed audits so you can avoid them in future. If you haven’t redirected log then you should do it now. Logs are destroyed whenever you restart your node if you are using docker.

Disqualified is by satellite are you disqualified on all?
Storagenode logs are noisy, spurious and the error text usually has nothing to do with the problem.
For instance, it won’t say you have been disqualified in the logs, will it?

Hi @andrew2.hart, the node is disqualified by all.
@nerdatwork, yes I am using docker but have lost all previous logs, will keep an eye on the new node I am spinning up now.

That’s unfortunate but it really doesn’t matter. The new node you start gets a clean slate as long as you use a new identity. Good luck!

1 Like

Ok, up and running! I already see it downloading data. I really don’t know what happened but again, I was trying to setup the node without port forwarding and let it powered down for a few days, probably that was it. Now with everything in place things went on smoothly. Thank you all for your help!
As a curiosity, I removed the 2TB USB drive and connected to an ISCSI LUN with 15TB on the raspberry 3.


Hmmm… Whilst I’m pretty sure that NFS or SMB shares are a no-no to run nodes on, I’m not 100% sure that ISCSI is a straightforward thing either.
I think it might be safer to run on a USB connection (although this is far from being my area of expertise, so if any of the clever guys could chime in…)

Alexy stated ISCSI is supported, but slower than direct attached storage. Since a USB drive is still not “direct” attachment, it may be a toss up as to which is better.

Iscsi is fine on a Pi 3 (Kernel v4 and above), although you are trading around 25% overhead on throughput compared to a USB attached storage enclosure. Pi 3 isn’t great for I/O on USB or Ethernet as it’s shared, you will find direct attached USB will be quicker, but overall you are going to be slower than a Pi 4 by at least 65% !

You will only really notice this on node start-up when it does the incredibly annoying filewalker process, that maxs out I/O while it scans the disk - but once this is done, your Pi 3 on Iscsi or USB is completely fine with current Storj client workload in my view :slight_smile:


Thanks! It’s my first node, glad to know that it’s supported by the network :grinning: