It took me several attempts until I got my node running. Have you set up a dynamic dns, that is where you put ADrESS: XnAC.dyndns.org:24… . Have you done port forwarding? The QNAP app isn’t updated. When I sit in front of my computer I’ll give you the path.
If you don’t have any other dockers running you can remove container station and reinstall it
You need to remove a previous container:
docker stop storagenode
docker rm storagenode
Then you can run a new one.
However this one
shows, that your storagenode already running and seems even doesn’t restart.
You can try to see a local dashboard:
docker exec -it storagenode ./dashboard.sh
Or at least check your logs:
docker logs --tail 10 storagenode
My IP address is a fixed IP and I have done open port forwading.
I would appreciate the steps, I have dedicated more than 20 hours and I can not find the solution, neither by GUI nor by commands
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
Internal 127.0.0.1:7778
External xxx.xxx.xxx.xxx:28967
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:
Especially
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
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 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.