Unusual ip adress to access the dashboard

First of all, I want to mention that the node is properly working and that this is not urgent*

Everything started to go wrong after I realized how having my NAS (which hosts Stor-J) in a DMZ was a frigging bad Idea. So, I put my unraid machine out of dmz and take the opportunity to specify to my already existing stor-j storage share to no exclude the second disk since only the first one was allowed and, well, that was redundant. BOOM as expected, dashboard down. After rebooting the docker with no success, i rebooted the NAS, with no much success either. After that point, even the whole machine seemed offline, since no ssh, no ping nor connection attempts to the NAS GUI worked BUT after some time trying to figure out what happened, everything came back in order… WEIRD
Anyway, I’m not here to talk about some weird unraid bugs but the aftermaths of what happened…
The thing is, the stor-j dashboard no longer uses the same IP as the NAS!
my local NAS IP is
but connecting to returns an unothorized connection (inaccessible)
And god knows how, I stumbled upon and well, that’s my good ol’ dashboard! (working)
Needless to say that this ip is out of my ip range / subnet and that it does not show as a device on my rooter / modem…
okok, where is the problem then I hear you asking!
I simply can’t access it on my local network, at all! The only way to access it is via the NAS itself (using the GUI boot)

Anyway to get it back online on my local network?

Some info that could be relevant:
Internet adress of the docker is tied to my DDNS which is correctly working
The network type of the docker is set on Bridge
There shouldn’t be any firewall problem

Oh and don’t worry, I didn’t get hacked after more than 40 000 loging attempts! :grin: Stay safe and use a strong password, my password manager saved my bacon here!
Thank you for the incoming help <3

1 Like

IPv4 address space has a few reserved subnets, two of which are called out in your post.

  • is reserved for the localhost…
  • is reserved for Private LAN…

Thus IP connections to are connections to the same machine that the program is running on.

What you’ve detailed above is normal behavior.

When logged into your NAS, the dashboard should always be accessible at … However, in order for the dashboard to be accessible from the LAN, you’ll need to allow connections to the port from the LAN addresses… those addresses on your LAN.

When running docker, you can use this option -p 14002:14002 instead of the one your are currently using for port 14002… which should result in the dashboard being accessible from the rest of your LAN.


Thank you, I’ll try that as soon as I can

I can’t seem to change the port mapping as you instructed since well, the port 14002 is already instructed in the container settings ( Dashboard port :14002 (when editing a container)) and the run command is the one given here (:point_down:)

docker run -d --restart unless-stopped -p 28967:28967 -p -e WALLET=“0xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX” -e EMAIL="user@example.com" -e ADDRESS=“domain.ddns.net:28967” -e BANDWIDTH=“20TB” -e STORAGE=“2TB” --mount type=bind,source="",destination=/app/identity --mount type=bind,source="",destination=/app/config --name storagenode storjlabs/storagenode:beta

Could I simply change the -p to ? or should I add -p after the first 2 ports?? being the local ip adress of the NAS and then send the whole command (while changing the values to the used one of course)?

Or could I simply add a “path” or “port” rule in the container settings?

Here is a Print Screen of a (blank) path configuration/rule that I could add

In this case, would the container path be and the host path be

I know that makes a whole lot of questions but I’m tired of messing everything at every modification that I make!

If possible, I would like the solution that will make it so that I won’t have to manually set the ports up again after an update.

Please and thank you!

Change this option to:

-p 14002:14002

  1. Stop the container: docker stop -t 300 storagenode
  2. Remove the container: docker rm storagenode
  3. Run a new container with the option changed.

 docker run -d --restart unless-stopped -p 14002:14002 -p 28967:28967 \
       -e WALLET="..."
       -e ....
1 Like

Sooooo… That kind of did it, some info wasn’t available at first, but everything came back except the used storage which shows 99% ( 4TB ) of free space, but that is the max and I know for sure that I already had some data stocked up.

Edit: sine the rm storagenode cmd didn’t work for an obscure reason, I deleted the docker using the GUI but also deleted the “image” which, thinking thinking back, must have destroy all of the data…
Oh well, another newbie mistake!

A great thank you! You just saved me a long day of trial and errors!

Deleting the image file would not delete any data your node may have stored.

If you believe you are missing data, check your mount points you used in your docker run command. If the mount points are not accurate, than your node will appear to have lost data and will eventually become disqualified.

Carefully look through your filesystem to make sure your incoming data pieces are being placed in the expected directory.

1 Like

Looking at the configuration, everything should be the same since this is the same share and directory that I previously had

This is the run command that I just used

… --mount type=bind,source="/mnt/user/Storj-storage/Identity/storagenode/",destination=/app/identity --mount type=bind,source="/mnt/user/Storj-storage/storage/",destination=/app/config --name storagenode storjlabs/storagenode:beta

And here is the previous one…

… --mount type=bind,source=’/mnt/user/Storj-storage/Identity/storagenode/’,destination=/app/identity --mount type=bind,source=’/mnt/user/Storj-storage/’,destination=/app/config --name storagenode storjlabs/storagenode:beta

Should I not specify the …/storage/ ?
This seems like this is the only difference but looking at the setting (first capture), it does point at the right place…
Finally, looking closely, the bandwidth used this month is flat except for yesterday…

To make things more clear, here is the arborescence of the files:

Storj-storage (share)
. config.yaml (file)
. revocations.db (file)
. trust-cache.json (file)
. Identity
… Storagenode
… ca. certs
… ca.key
… identity.certs
… identity.key
… etc.
. Storage
… I do not have the rights to see what’s inside storage

My guess is that you want to use the previous mount point… but it’s difficult for me to tell from your posts.

In either case, you should stop the docker container until you are sure of which mount point to use.

If you have root terminal access to your NAS, you can check the directories and the file system for exactly where all previous has been stored.

In the terminal:

ls -l /mnt/user/Storj-storage/

and then

ls -l /mnt/user/Storj-storage/storage/

should give you a clue as to which mount point is correct.

You shure are right, unfortunately, that was a little to late!
The node did get disqualified
I tried to reinstall everything using the last run cmd (witouth the /storage/ ) and well, it is all back to normal… is what I would say but the node is offline since it got disqualified. ARH!

now… I guess that I’ll start over, delete my existing share, sign a new identity etc…

Anyway, thanks for the help, it was very helpful

In any docker setups the storage path should not end with the storage, if you previously started the storagenode.
Because when you start the storagenode in a first time, it creates a storage folder in the specified source mount point.
If you specify the source path with the storage at the end for that storagenode, it will create another storage folder inside and start from scratch. The result is disqualification.

1 Like

If I add -p 14002:14002 to the command, and I allow firewall exception on the NAS, what IP would i use to remotely access the Dashboard?

IP of your PC/NAS with storagenode

1 Like