the identity is separate from the rest of the storagenode, so you simply place the identity the correct place and continue as you and already done the setup command, you will be designating your identity path in the docker run command anyways.
sorry it took so long for someone to reply.
so in short you have complete the SETUP=“true” part, simply move on to the next step.
I have a friend who runs storj and is an experienced system administrator (but maybe not expert in how storj works). His suggestion was to delete the mount point
sudo rm /mnt/storj/config.yaml
…and then run the docker run command again. Does that sound right?
Since you have already setup up the node once, you don’t need to run the SETUP="true" step again. First you should stop and remove the existing docker container.
Thank you! With a hybrid of these instrux and my friend, I think it’s now up and running. When I ran the command it was continually restarting, so he had me delete the mount point, run with the SETUP flag again, and then run without the SETUP flag. It appears to be working well. I’m not at home now, and haven’t opened the port for the web dashboard, so I’ll be checking that in a couple hours. (I could probably get to it with an SSH tunnel, but all that is kinda new to me and a little time consuming to sort out, so I’ll just report back when I get home.)
There seems to have been a problem with the original mount location versus the new one. So we didn’t delete the mount, we just deleted all of the data in it It was starting up and dying like this: (note I added manual newlines for readability)
2021-04-30T17:31:57.154Z ERROR
services unexpected shutdown of a runner
{"name": "piecestore:monitor",
"error": "piecestore monitor: error verifying location and/or readability of storage directory: open config/storage/storage-dir-verification: no such file or directory",
"errorVerbose": "piecestore monitor: error verifying location and/or readability of storage directory: open config/storage/storage-dir-verification: no such file or directory\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func1.1:131\n\tstorj.io/common/sync2.(*Cycle).Run:92\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func1:128\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"}
Strangely, it had been able to write to the drive, the various databases all had an up-to-date mtime. But the storage-dir-verification file was absent and the databases didn’t have the -shm and -wal components.
I’ll tell you what I did, but I’m also kind of a novice, so I can’t say how likely it is to work for you, or that it won’t have some weird side effect. I’ll leave it to others to comment on whether your situation is the same as mine.
Then, run the “setup” command (the one that contains “-e SETUP=true”) again, and finally run your the docker run command as described in the instructions (with the values for your wallet, email address, server address etc. in it).
the storagenode reboots when it cannot establish a connection to the internet, usually this means your ports aren’t fowarded correct from your router.
or other such internet connection issues… wrong ip, incorrect global ip given to the storagenode or something in that regard…
to tell more accurately what is going on you can check the storagenode log.
don’t do rm -rf commands on your storagenode in case you delete it and then will have to start over with generating identity and such.
My ports were forwarded correctly. I think it restarted indefinitely just because I didn’t erased the previous storage directory content, so I was not able to run the SETUP command due to the previous config.yaml.
I did this because my previous node was disqualified so I generated a new identity.
Have a nice day
Very glad that helped. My node is up and running, I’ve accessed the dashboard both on the home network and remotely via SSH tunnel. Yay! One mystery…so far it has about 1 GB network activity and 2 GB of disk space. So, how does it manage to use more space on my disk thank it transmits over the network?! I guess it has something to do with compression…but it’s not what I expected!
If your node was running successfully, do not delete its data, otherwise the identity tied to that data will be disqualified.
The node will not download deleted data back. Instead, your node will be kicked off the network.
Deleting data can be done only with the related identity altogether. They useless without each other.
Yes it’s an important information you’re giving here, i’ll update my previous post to prevent anybody doing wrong. I deleted my storage data because I was already disqualified by the network !