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 192.168.2.13
but connecting to 192.168.2.13:14002 returns an unothorized connection (inaccessible)
And god knows how, I stumbled upon 127.0.0.1:14002 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! Stay safe and use a strong password, my password manager saved my bacon here!
Thank you for the incoming help <3
IPv4 address space has a few reserved subnets, two of which are called out in your post.
127.0.0.0/8 is reserved for the localhostâŚ
192.168.0.0/16 is reserved for Private LANâŚ
Thus IP connections to 127.0.0.1 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 127.0.0.1:14002 ⌠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 192.168.2.0/24 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.
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 ()
Could I simply change the -p 127.0.0.1:14002:14002 to 192.168.2.13:14002:14002 ? or should I add -p 192.168.2.13:14002:14002 after the first 2 ports??
192.168.2.13 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
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.
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
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âŚ
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.
Stay safe and use a strong password, my password manager saved my bacon here!
)
