Need Help: QNAP Storj App V. 1.1.4 Not Working

I have done this, I erase everything, start from scratch and I already have the container running! It is an important advance!!!
However, when I apply this command
docker exec -it storagenode ./
I get
Uptime 3m21s

                Available Used Egress Ingress

Bandwidth N/A 0 B 0 B 0 B (since May 1)
Disk 80.00 TB 0 B


If I enter the [intenalIP]:14002 through the browser
Show me STATUS OFFLINE and QUIC Misconfigured
(I can’t attach a screenshot because the system only allows me 1)

With this command, show me errors
docker logs --tail 10 storagenode

QNAP have internet conection and the port 28967 is port forwading in the router
The storage folder was empty, after creating the node there are now files and folders

Ok. Now this is a usual OFFLINE issue. So you fixed any docker-related issues and now node at least running.
You can use this checklist to troubleshoot the offline issue:

Please pay attention to WAN IP on your router (usually shown on the Status page) - it should match the IP on Open Port Check Tool - Test Port Forwarding on Your Router, otherwise port forwarding will not work (and no-ip will not help). And of course you should use this IP with node’s port in your docker run command as a value for ADDRESS variable.
To update any parameter to your node you need to stop and remove the container and run it back with all your parameters include changed ones.

Please show me the docker run-command you are using to run the node. It is very close now. Do you have the correct permission on the folders to run? Try also sudo the docker run command.

As you can see it’s already running, but have connectivity problems, so seems permissions and path issues are already solved.

Ok. Now it’s time to show the portforwarding from the router.

2 rules, one for UDP and one for TCP.

in the -e ADDRESS=“your.public.static.ip:28967”.

@Alexey What issue is it left to get the node connected?

This checklist:


Hello, the ports already seem operational and open I have also seen that the logs no longer appear errors, at least I do not see.
Storage Node Dashboard ( Node Version: v1.53.1 )

Uptime 34h58m20s

                              Available        Used        Egress     Ingress
 Bandwidth           N/A                2.38 GB     181.34 MB     2.20 GB (since May 1)
      Disk                 80.00 TB     2.19 GB

External xx.xx.x.xx:28967

However in the portal I still appear “QUIC Misconfigured” in red color

Is it correct or should another message come out?

did you remember

-p 28967:28967/udp

and to open the UDP ports on the router?

Yes, I just checked, although with a UDP checker tells me that it is closed I will review it tomorrow, because everything is well configured

If you did configure it while the node is running, you need to restart the node to apply the changes - it checks UDP only on start.

Congratz! I saw that you dedicated 81TB. To be honest, I think you’ll never use up the space on a single node. If I remember correctly, maximum size on a node is 24 TB. My 3TB node took 16 months to fill.

The UDP is configured from the beginning, I have not made any subsequent changes.
I have performed a check with the tool
UDP Port Checker Online - Open Port to port 28967 and to the internal QNAP IP and it gives me close.
However, in docker it appears open and configured. I don’t have any firewall configured in QNAP

Yes, that’s right, 81 TB, I didn’t see in the documentation any limitation in this regard, now I see it.
A question I have, can I have several nodes under the same identity in the same QNAP in different 24 TB containers? The idea would be to add storage in the same QNAP

Please make sure that you allowed the 28967 UDP port in the inbound rules of your firewall and that the docker run command have -p 28967:28967/tcp -p 28967:28967/udp parameters.

There is no limitations. You can allocate any size. Just with current usage the node(s) cannot fill up more than 24TB of used space in one location due to equality of uploads and deletions at this point.
So, doesn’t matter how many nodes you would have in one location (/24 subnet of public IPs), they all treated as a one node for uploads and as a different ones for audits, customers’ egress, egress repair traffic and online checks.

I am sure that they are open in docker, this is the command that was sent when creating it and it was not modified later as it also indicates
docker run -d --restart unless-stopped --stop-timeout 300
-p 28967:28967/tcp
-p 28967:28967/udp
-p 14002:14002 \

I have tried with command line “telnet 28967” and with putty, in both cases it does not establish connection ( is the LAN ip).

It’s not that there is a strict limit (@ligloo is mistaken here). However, nodes just store customer data and so far there was just not enough customer data to fill more than few tens of TB per node. What @ligloo referred to is the estimated amount of data we can reasonably expect now from customers, under a lot of assumptions in terms of how customers actually use Storj and under assumption that the node works for many years. Also, as Storj gains more and more customers who want to store more and more data, this number might grow.

You can have multiple nodes collecting data at the same time, but if they’re behind the same IP address, they will all be considered as one for the purposes of ingress.

Ok, Regards
I still need to fix the error in the previous post

The documentation lists a recommendation, not a hard limit. Others have already mentioned this, I just wanted to point you to this: Realistic earnings estimator
That estimator will give you the best estimation I can give you as to how quickly you can expect your node to fill up on a single /24 IP range. Technically the soft limit where deletes roughly match ingress is around 40TB atm, but it’s not longer so relevant as getting close to that will take decades as the growth slows over time. The estimator shows an estimation of the first 10 years.

There is no text/http interface on the node’s port, you need to use dRPC requests, not telnet.

Please check or show your port forwarding rule(s) for this node on the router - it should have UDP 28967 port.

This is the open port in the router, is a Fortigate Fierwall

The port TCP 28967 runs correctly
UDP with nMAP internal IP
28967 UDP