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 ./dashboard.sh
I get
ID XXXXXXX
Status OFFLINE
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.
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 )
ID
Status ONLINE
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
Internal 127.0.0.1:7778
External xx.xx.x.xx:28967
However in the portal I still appear “QUIC Misconfigured” in red color
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 192.168.100.50 28967” and with putty, in both cases it does not establish connection (192.168.100.50 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.
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.
