Please check your -e ADDRESS option, it must use either the public IP which matches the WAN IP and IP from yougetsignal or DDNS hostname and have a public port (in your case 10000), e.g. -e ADDRESS=my.public.address:10000
Please note, if you have a dynamic public IP, it’s better to use a DDNS hostname instead, otherwise you would be forced to update your docker run command with a new public IP every time, when the ISP would change it. This requires also to stop and remove the container and run it back with all your parameters include the changed one.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
47451e87b617 storjlabs/storagenode:latest "/entrypoint" 15 hours ago Up 15 hours 192.168.0.2:14002->14002/tcp, 0.0.0.0:10000->28967/tcp, 0.0.0.0:10000->28967/udp, [::]:10000->28967/tcp, [::]:10000->28967/udp storagenode
4f27619801bc storjlabs/watchtower "/watchtower storage…" 17 hours ago Up 16 hours watchtower
so at least it does not crash, i had issues with that yesterday
Did you change the listening address (server.address:) in your docker run command or in the config.yaml file?
Is it possible that it is not 28967 any longer?
Please also check your DDNS hostname:
nslookup raspberrypi.tail9ee2.ts.net 8.8.8.8
It should return the same IP as a WAN IP and the IP from yougetsignal.
That’s the culprit, if they do not match, it will never work. Please check your DDNS updater, it should update this hostname to your current external IP.
In that case you need to contact your ISP and ask for a public IP, it could be a dynamic, but must be a public (the WAN IP will match the IP on yougetsignal).
The DDNS will not solve the issue with a CGNAT, it can solve only the problem when your public IP is dynamic. With CGNAT you do not have a public IP either.
i do not have one, tailscale handles that… ie match the external ip to the hostname they give me
i did that a year ago or so… no luck, and that is why i started using tailscale so that a friend can backup to my openmediavault and i can back to him… ie we use tailscale to get past the cg-nat issue
also i do this testing from my windows machine that do not use tailscale at all… so my windows outgoing connection is different that the raspberry pi…
that makes me think… what inerface/local ip does the storj client listen to? if it picks the local network one i can see why it might fail… it needs to listen on the interface that tailscale creates
4: tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 100.69.111.59/32 scope global tailscale0
valid_lft forever preferred_lft forever
inet6 fd7a:115c:a1e0::9301:6f3b/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::caa8:4da8:5213:3903/64 scope link stable-privacy
valid_lft forever preferred_lft forever
just for fun i tried to change where it listens but now the app is gone… ie the web interface
# server address of the api gateway and frontend app
console.address: 192.168.0.2:14002
# the public address of the node, useful for nodes behind NAT
contact.external-address: "raspberrypi.tail9ee2.ts.net"
# public address to listen on
server.address: 100.69.111.59:28967
maybe it was the private address i should change?
private address to listen on
server.private-address: 127.0.0.1:7778
hmm i tried to change that in the config.yaml to
# private address to listen on
server.private-address: 100.69.111.59:10000
now the interface is dead again…
EDIT… decided to start all over with new identity… i still have a backup of identity but since i have not reached “production” yet i take there is no harm… and i will take carefull notes of everything i have done
Q… i issued ./identity create storagenode --identity-dir /media/storj/identity as i want the files to be created on the external drive of the pi rather than on the sd card
when i sign with my token… does the identity dir part come before or after email/token? i tried to google this but no luck and i dont want to F it up
Only in a case of a dual stack, the public IPv4 is mandatory, IPv6 is optional.
the node will bind to all interfaces by default, however, if your tunnel is not established when the node is started, I guess it will not listen it.
You may try to bind the node only to tailscale0 interface using its IP in your docker run command with the option -p 100.69.111.59:10000:28967/tcp -p 100.69.111.59:10000:28967/udp -e ADDRESS=raspberrypi.tail9ee2.ts.net:10000
But if the IP would change, you will need to update it. Also the node wouldn’t start, if the tunnel is not open.
You shouldn’t change that, especially using the same ports for all these private addresses, they must be unique. In the case of docker it’s also makes no sense, because the container is running in an isolated network behind the docker NAT called the “bridge”, so it wouldn’t be possible to bind to the external address from the docker container, unless you would disable the bridge with the option --network host in your docker run command before the image name. In the latter case you may remove all -p options, because they wouldn’t have any effect and update only
server.address: 100.69.111.59:10000
option either in the config.yaml file or as a command line argument --server.address=100.69.111.59:10000 after the image name in your docker run command (the command line options have a precedence above the options in the config file).
You may use the --network host option before the image name in your docker run command, then all addresses would be exposed to the host, because the NAT will not be used in that case, but perhaps it’s not needed. So, please revert back your changes and do not touch config.yaml anymore. The mentioned change to -p 100.69.111.59:10000:28967/tcp -p 100.69.111.59:10000:28967/udp -e ADDRESS=raspberrypi.tail9ee2.ts.net:10000 should be enough.
they do never change once a machine is registered with tailscale
i forgot about docker, but is my thinking wrong if i wanted to disable the NAT? i mean since this is a purpose build pi that will never run anything else, why have an extra nat? to me that just makes it more complex… just a thought, i could be barking up the wrong tree