Can't load the Dashboard at 14002

Hi there!

I have installed the docker at a synology NAS and I installed the storagenode, according to your instructions (Storage Node - Storj Node Operator Docs). The problem I am facing now is that the Dashboard is not reachable under the port 14002.

I have made my research at your Forums already and I realized that the problem is because the command had the option “-p 127.0.0.1:14002:14002” instead of having “-p 14002:14002”.

Now the dashboard is theoretically reachable only on localhost, but this doesn’t make sense on a Synology NAS, as it should be reachable via the local IP of the Synology. Which means that I can’t reach is from any computer in the same network, because it is limited to 127.0.0.1.

I also tried to fix that by removing the relevant rule in iptables, under the chain “DOCKER” and adding it again with 0.0.0.0 as destination, but that didn’t do the trick.

In addition I tried to change in on the docker container by using the command “docker run -p 14002:14002 -td storjlabs/storagenode”, but that also didn’t work.

Would you be so kind to help me change the 127.0.0.1 into 0.0.0.0 on the port settings of the docker container?

With kind regards,
Angelos Pitsos

Hello @apitsos ,
Welcome to the forum!

Please stop and remove your container:

docker stop -t 300 storagenode
docker rm storagenode

then run it back, using your full docker run command with all your parameters, but update the option -p 127.0.0.1:14002:14002 to -p 14002:14002.
After that please add 14002 TCP port to the allowed ports in your firewall on Synology. You should also allow TCP 28967 and UDP 28967.
Make sure to forward only 28967 TCP+UDP on your router.
To have a remote access to your dashboard you may use this instruction: How to remote access the web dashboard - Storj Node Operator Docs
It will also allow to connect to your dashboard from LAN even if you would not modify the port mapping in your docker run command.

Hi @Alexey,

Thanks a lot for your quick respond and this is also much appreciated. I understand what you say and I would say that I was expecting this answer, but I am wondering, wouldn’t that ruin the “satellite” data already saved on my NAS and what is already built? Or that way it will continue like it was before and all and all there will be a downtime of a couple of minutes?

With regards,
Angelos Pitsos

No. The first thing - the satellite is an address book, audit, repair and payment service. Data is flowing directly between customers (of said satellite) and your node, the satellite doesn’t act as an proxy.

If you mounted your drive from the NAS (not a docker volume), data will be in safe. Docker containers are designed to be ephemeral - they can be removed in any time and it should not affect data (if properly configured).

So, in short - it’s safe to remove the container, if you followed our guide. When you run a container, it will continue at point where is it removed.
But yes, there would be a downtime probably detected, if your node is new, the online score will be affected as well (because it’s younger than a month). But if it’s old - the online score unlikely be affected.

By the way, to recover the online score your node should be online for the next 30 days. Each downtime requires additional 30 days to recover.

Hey @Alexey,

That did the trick, but now I have the following issue:

Is there something I should do in order to fix that problem?

With kind regards,
Angelos Pitsos

Yes, you need to forward UDP 28967 on your router and allow it in your firewall.
See also Step 4. Configure QUIC - Storj Node Operator Docs

You can ignore it. UDP traffic is close to 0.

Hi @Alexey,

The ports were already forwarded, but I found this article: Linux Configuration for UDP - Storj Node Operator Docs

So I suppose I need to proceed with that as well. I tried already, but on the second command (echo “net.core.rmem_max=2500000” >> /etc/sysctl.d/udp_buffer.conf) I get the following feedback:
/etc/sysctl.d/udp_buffer.conf: No such file or directory

Again, this is a Synology NAS.

Would you be so kind to help me here, how can I configure that on a way to stay like that (2.5 MB) also after a reboot?

And also, if this is running already (because I executed the other commands), shouldn’t I see the “Misconfigured” going away?

With kind regards,
Angelos Pitsos

Seems they do not have this path. You may try to create this folder first, perhaps it could recognize it.
You may check it after the change:

sysctl net.core.rmem_max

the QUIC availability is checked on each chek-in on the satellite (every hour by default), so if your node become available via UDP, it will be changed to OK.
However, the buffer change likely would be applied after re-creation of the container.

Hi @Alexey,

Thanks a lot for your replies. I appreciate your support. I did exactly like you say. First of all, before I create the folder “sysctl.d” I ran the command:

sysctl net.core.rmem_max

That returned the result:

net.core.rmem_max = 2500000

This shows me that the setting was already configured to 2.5MB. So I did a restart to the service:

docker restart -t 300 DC-HEL-NAS02_a

…but it didn’t help. I was still seeing the red “Misconfigured”.

Then I created the directory “sysctl.d” as suggested and I ran the commands described in this article: /quic-requirements/linux-configuration-for-udp

I proceeded with the restart of the Synology NAS in order to prove if the setting of 2.5MB remains. After restart I ran again the command:

sysctl net.core.rmem_max

And the setting remains, because I got the following result:

net.core.rmem_max = 2500000

So we have succeeded here!

But the problem with QUIC remains, because is still showing “Misconfigured”. I don’t understand how is that possible. I forward both TCP and UDP protocol for port 28967 as incoming traffic to the NAS. Should I also allow any outgoing traffic? If yes, on which port/protocol?

Please advise me…

With kind regards,
Angelos Pitsos

this is because your node is still not reachable via UDP.
The increasing a buffer size is the second step after you fix an issue with unavailability via UDP.

So, please check your docker run command, it must have

-p 28967:28967/tcp \
-p 28967:28967/udp \

Both ports UDP 28967 and TCP 28967 should be forwarded on your router to your Synology.
Both ports UDP 28967 and TCP 28967 should be allowed in your firewall on Synology. Most of firewalls requires to have a separate rules for TCP and for UDP, so you likely should have two rules here - one for TCP 28967 and the second for UDP 28967.

Hi @Alexey,

Thanks a lot for your answer. The thing here is that I have forwarded properly both TCP and UDP ports on the router and also allowed from the firewall. But I would like to stay on the following sentence:

Does that mean that is not enough that I have them both TCP and UDP in the command for run the Docker container? I didn’t know that Synology has its own firewall.

Would you be so kind to advise me how can I check and also how to configure the firewall of Synology properly?

Kind regards,
Angelos Pitsos

I do not have a Synology NAS on my hands, but it likely has some firewall. Please try to use their documentation or search across the interface.

Hi @Alexey,

Actually I just found it and configured already. Here is what I allow:

It is really very strange that the QUIC still shows “Misconfigured”. I also restarted the container in order to force the check, but again, that shows “Misconfigured”.

On the other hand, the QNAP node I setup yesterday and which is behind a Mikrotik Router/Firewall as well, worked like a charm. From the first moment the QUIC was with a green “OK”.

With regards,
Angelos Pitsos

Then it perhaps a Synology-specific,
see also
https://forum.storj.io/search?expanded=true&q=tags%3Asynology-nas%2Bquic-udp

Hey @Alexey,

After two days of troubleshooting I managed to solve the problem. You can’t imagine…

My Synology is in a datacenter and it has several interfaces. The STORJ service approaches the Synology on the “Public” address. But under networking I had as “Default Gateway” the IP and the gateway of another interface, which was for internal use (Management interface).

As soon as I changed the default gateway and put the one from the “public” interface, the QUIC became green “OK”.

I would like to thank you very much for your support and all the efforts. It is very much appreciated.

With kind regards,
Angelos Pitsos

1 Like

And something more. The firewall settings on Synology do not affect the service. I removed them and the QUIC is still green. That means that the ports are allowed, most probably because they are already configured in the Docker container.