Setup: storagenode configuration already exists (I messed it up once)

I feel so close to getting up and running, but I made a dumb mistake!

I ran the “Setup” instructions here: Storage Node - Node Operator

But my first time through, I left “/storagenode/” off the identity path.

So I ran it again, with the correct path. But now I get this error:
Error: storagenode configuration already exists (/app/config)

So how do I get rid of the faulty setup configuration and try again?

1 Like

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.

Thanks! But I’m not sure I understand. It is the docker run command that is giving me the error:

docker run --rm -e SETUP="true"     --mount type=bind,source="/home/pete/.local/share/storj/identity/storagenode/",destination=/app/identity     --mount type=bind,source="/mnt/storj",destination=/app/config     --name storagenode storjlabs/storagenode:latest 2021-04-30T00:48:32.218Z        INFO    Configuration loaded    {"Location": "/app/config/config.yaml"}
Error: storagenode configuration already exists (/app/config)

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?

Hi o1eal,

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.

docker stop -t 300 storagenode
docker rm storagenode

Next, modify the normal run command with your parameters, including the corrected identity location and the original storage location.

docker run -d --restart unless-stopped --stop-timeout 300 \
    -p 28967:28967 \
    -p 127.0.0.1:14002:14002 \
    -e WALLET="0xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
    -e EMAIL="user@example.com" \
    -e ADDRESS="domain.ddns.net:28967" \
    -e STORAGE="2TB" \
    --mount type=bind,source="<identity-dir>",destination=/app/identity \
    --mount type=bind,source="<storage-dir>",destination=/app/config \
    --name storagenode storjlabs/storagenode:latest

This should start your node.

(just an expansion on SGC’s answer)

I don’t have a docker process called “storagenode” running. Not sure I ever have, yet…

thats fine just do this

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.)

1 Like

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 :slight_smile: 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.

TLDR, delete worked. It’s successfully receiving blocks now.

1 Like

Hello,

I am having the exact same problem, I am currently at the step where the container keeps restarting indefinitely.

Can you please give precision on what you did exactly ? @tedder @o1eal

Here is a piece of logs of my storagenode container

Thank you.

Hi Bisouke,

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.

docker stop storagenode
docker rm storagenode
rm -rf /mnt/storj/*

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).

Hope this helps!

1 Like

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.

1 Like

Thank you very much @o1eal I did what you said and it worked for me :slight_smile:
To sum up here is what I did :

  1. docker stop storagenode

Which stop the container

  1. docker rm storagenode

Which delete the container

  1. Then I deleted everything that was in my storage location (the “storage-dir”)

WARNING : I did this because my node was already disqualified, don’t delete your storage data if you’re node is doing well.

@o1eal did this with his rm -rf /mnt/storj/* command but it is specific to our storage location

  1. I ran the setup command docker run --rm -e SETUP=“true” --mount […]

Which I was not able to run before because I had already configured a storj node before

  1. And then the run command

docker run -d --restart unless-stopped --stop-timeout 300 \ […]

Now it runs well :wink:

Thank you very much for your help !

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 :sun_with_face:

1 Like

my bad, wasn’t very helpful because i didn’t consider a lot of relevant things.

1 Like

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!

1 Like

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.

2 Likes

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 !

2 Likes