Docker: invalid reference format: repository name must be lowercase

Hey,

I’m trying to start the node through PowerShell and below is my command:

docker run --rm -e SETUP=“true” -v type=bind, source=“C:\Users\User1\Desktop\identity-hosts\nodes”,destination=/app/identity -v type=bind, source=“F:\node2”,destination=/app/config --name nodeone storjlabs/storagenode:latest

And for some strange reason I’m getting:

docker: invalid reference format: repository name must be lowercase.

Is “nodeone” already not in lowercase, I don’t get it.

I will appreciate your guidance.

Kind regards,

You’ve got spaces in wrong places.

The correct command for setup (with assuming that your identity - 6 files are located in "C:\Users\User1\Desktop\identity-hosts\nodes\storagenode2"):

docker run --rm -e SETUP="true" --mount type=bind,source="C:\Users\User1\Desktop\identity-hosts\nodes\storagenode2",destination=/app/identity --mount type=bind,source="F:\node2",destination=/app/config --name storagenode storjlabs/storagenode:latest

Where you took -v and why you added space after each comma?
Please do not you use any word processors, use Notepad++ or VisualStudio Code instead.

This command should be executed only once for entire node’s life.
After the setup is done, please carefully copy the docker run command for actual run and modify parameters, then execute.

Hello Alexey,

Thank you for reaching back.

I ran the command as you have specified exactly, and I have again met the previous errors that I have shared in my original thread - that is the “docker run” with my parameters, which I have done as:

docker run -d --restart unless-stopped --stop-timeout 500 -p 28967:28967/tcp -p 28967:28967/udp -p 14002:14002 -e WALLET=“NUMBERS” -e EMAIL=“email@gmail.com” -e ADDRESS=“voidbox.ddns.net:28967” -e STORAGE=“850GB” --mount type=bind,source=“C:\Users\User1\Desktop\identity-hosts\nodes\storagenode2”,destination=/app/identity --mount type=bind,source=“F:\node2”,destination=/app/config --name storagenode storjlabs/storagenode:latest

It is possible that this is related to my identity, as I can go ahead and start from scratch with a new one, again.

Kind regards,

Please copy result of the command executed in PowerShell:

ls C:\Users\User1\Desktop\identity-hosts\nodes\

And please provide an error, which you have now. To make it pretty formatted, place the text between two new lines with three backticks, like this

```
error or docker run command
```

Hey Alexey,

This is the output:

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----          3/8/2022  11:25 PM           1088 ca.cert
-a----          3/8/2022  11:20 PM            241 ca.key
-a----          3/8/2022  11:25 PM           1626 identity.cert
-a----          3/8/2022  11:20 PM            241 identity.key

So, you do not have a subfolder there.
Can you please check your identity: Identity | Storj Docs
Replace "$env:AppData\Storj\Identity\storagenode\" with "C:\Users\User1\Desktop\identity-hosts\nodes\"

The mount option for identity would be --mount type=bind,source="C:\Users\User1\Desktop\identity-hosts\nodes\",destination=/app/identity

Make sure that you use straight quotes " and not curly ones like and - they are invalid for shell.
Please do not use any word processors to form your docker run command, use Notepad++ or VisualStudio Code instead.
There should not be any curly quotes, hyphens instead of dashes and so on.

Hello Alexey,

I do appreciate the response on this matter.

Apologies for any caused inconvenience, but the below is my actual setup with the actual locations of my files, as I previously used masked examples:

Checked the identity, all good following the guide and the results that I should be getting:

(sls BEGIN "C:\Users\Rumen\Desktop\identity-hosts\identity\ca.cert").count
2
(sls BEGIN "C:\Users\Rumen\Desktop\identity-hosts\identity\identity.cert").count
3

So just to clarify - this is what I have used for my setup:

docker run --rm -e SETUP="true" --mount type=bind,source="C:\Users\Rumen\Desktop\identity-hosts\identity",destination=/app/identity --mount type=bind,source="F:\node2",destination=/app/config --name node2 storjlabs/storagenode:latest

And this is what I have used for starting the node:

docker run -d --restart unless-stopped --stop-timeout 500 -p 28967:28967/tcp -p 28967:28967/udp -p 14002:14002 -e WALLET="ADDRESS" -e EMAIL="ADDRESS" -e ADDRESS="voidbox.ddns.net:28967" -e STORAGE="850GB" --mount type=bind,source="C:\Users\Rumen\Desktop\identity-hosts\identity",destination=/app/identity --mount type=bind,source="F:\node2",destination=/app/config --name node2 storjlabs/storagenode:latest

Then all looks correct, what is error do you have now?

Hello Alexey,

I have run the commands as we have discussed and this is the output of my docker run log as soon as I ran it - kindly give me a few days to monitor and see if everything goes well before we close this tread:

2022-03-29 12:29:59,965 CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the config file.  If you intend to run as root, you can set user=root in the config file to avoid this message.
2022-03-29 12:29:59,973 INFO RPC interface 'supervisor' initialized
2022-03-29 12:29:59,973 CRIT Server 'inet_http_server' running without any HTTP authentication checking
2022-03-29 12:29:59,973 INFO supervisord started with pid 1
2022-03-29 12:30:00,978 INFO spawned: 'processes' with pid 35
2022-03-29 12:30:00,986 INFO spawned: 'storagenode' with pid 36
2022-03-29 12:30:00,992 INFO spawned: 'storagenode-updater' with pid 37
2022-03-29T12:30:01.023Z        INFO    Configuration loaded    {"Location": "/app/config/config.yaml"}
2022-03-29T12:30:01.023Z        INFO    Invalid configuration file key  {"Key": "operator.email"}
2022-03-29T12:30:01.023Z        INFO    Invalid configuration file key  {"Key": "storage.allocated-disk-space"}
2022-03-29T12:30:01.023Z        INFO    Invalid configuration file key  {"Key": "operator.wallet-features"}
2022-03-29T12:30:01.023Z        INFO    Invalid configuration file key  {"Key": "contact.external-address"}
2022-03-29T12:30:01.023Z        INFO    Invalid configuration file key  {"Key": "server.address"}
2022-03-29T12:30:01.023Z        INFO    Invalid configuration file key  {"Key": "storage.allocated-bandwidth"}
2022-03-29T12:30:01.023Z        INFO    Invalid configuration file key  {"Key": "console.address"}
2022-03-29T12:30:01.023Z        INFO    Invalid configuration file key  {"Key": "server.private-address"}
2022-03-29T12:30:01.023Z        INFO    Invalid configuration file key  {"Key": "operator.wallet"}
2022-03-29T12:30:01.023Z        INFO    Invalid configuration file value for key        {"Key": "log.level"}
2022-03-29T12:30:01.023Z        INFO    Invalid configuration file value for key        {"Key": "log.development"}
2022-03-29T12:30:01.029Z        INFO    Running on version      {"Service": "storagenode-updater", "Version": "v1.50.4"}
2022-03-29T12:30:01.030Z        INFO    Downloading versions.   {"Server Address": "https://version.storj.io"}
2022-03-29T12:30:01.049Z        INFO    Configuration loaded    {"Location": "/app/config/config.yaml"}
2022-03-29T12:30:01.056Z        INFO    Operator email  {"Address": "ADDRESS"}
2022-03-29T12:30:01.056Z        INFO    Operator wallet {"Address": "ADDRESS"}
2022-03-29T12:30:01.160Z        INFO    db      database does not exist {"database": "info"}
2022-03-29T12:30:01.162Z        INFO    db      database does not exist {"database": "bandwidth"}
2022-03-29T12:30:01.164Z        INFO    db      database does not exist {"database": "orders"}
2022-03-29T12:30:01.165Z        INFO    db      database does not exist {"database": "piece_expiration"}
2022-03-29T12:30:01.167Z        INFO    db      database does not exist {"database": "pieceinfo"}
2022-03-29T12:30:01.169Z        INFO    db      database does not exist {"database": "piece_spaced_used"}
2022-03-29T12:30:01.170Z        INFO    db      database does not exist {"database": "reputation"}
2022-03-29T12:30:01.172Z        INFO    db      database does not exist {"database": "storage_usage"}
2022-03-29T12:30:01.174Z        INFO    db      database does not exist {"database": "used_serial"}
2022-03-29T12:30:01.175Z        INFO    db      database does not exist {"database": "satellites"}
2022-03-29T12:30:01.177Z        INFO    db      database does not exist {"database": "notifications"}
2022-03-29T12:30:01.179Z        INFO    db      database does not exist {"database": "heldamount"}
2022-03-29T12:30:01.181Z        INFO    db      database does not exist {"database": "pricing"}
2022-03-29T12:30:01.184Z        INFO    db      database does not exist {"database": "secret"}
2022-03-29T12:30:01.558Z        INFO    Current binary version  {"Service": "storagenode", "Version": "v1.50.4"}
2022-03-29T12:30:01.558Z        INFO    Version is up to date   {"Service": "storagenode"}
2022-03-29T12:30:01.574Z        INFO    Current binary version  {"Service": "storagenode-updater", "Version": "v1.50.4"}
2022-03-29T12:30:01.574Z        INFO    Version is up to date   {"Service": "storagenode-updater"}
2022-03-29 12:30:02,576 INFO success: processes entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2022-03-29 12:30:02,576 INFO success: storagenode entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2022-03-29 12:30:02,576 INFO success: storagenode-updater entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2022-03-29T12:30:18.557Z        INFO    Telemetry enabled       {"instance ID": "1mpseQ1dKctbLyQZxBz4KBjCHCVkQCPFx8wQKddneRp6oHa7Tz"}

And this is how I setup afterwards the watcher - since it will make sure that my node won’t go down and keep it updated, as far as I was able to understand:

docker run -d --restart=always --name watchtower -v /var/run/docker.sock:/var/run/docker.sock storjlabs/watchtower node2 watchtower --stop-timeout 300s

No log for that at the moment.

And once last thing - I noticed that the process of virtualization is taking a lot of my RAM, not quite sure if that is normal, if you can kindly let me know if it is possible to somehow limit the allocated RAM, as I doubt that this much is required for my node:

Looking forward to your response and thank you in advance!

Yes, the Linux virtual machine consumes more RAM than needed.
Did you redirect logs to the file? If so, please provide 20 last lines from it.
Otherwise your storagenode should have more logs on this time.

Hey Alexey,

I understand.

Otherwise, I can see that information is being uploaded as it should, however, I can see some attempts which result in error, here are some examples:

2022-03-29T19:38:52.606Z        ERROR   piecestore      upload failed   {"Piece ID": "6V25VDWU22VDMPFH4TRK5CTEVFEM7PMMIHWKGGFSR7BLZ23U3X4Q", "Satellite ID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Action": "PUT", "error": "order: grace period passed for order limit", "errorVerbose": "order: grace period passed for order limit\n\tstorj.io/storj/storagenode/orders.(*FileStore).BeginEnqueue:86\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).beginSaveOrder:696\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).Upload:318\n\tstorj.io/common/pb.DRPCPiecestoreDescription.Method.func1:220\n\tstorj.io/drpc/drpcmux.(*Mux).HandleRPC:33\n\tstorj.io/common/rpc/rpctracing.(*Handler).HandleRPC:58\n\tstorj.io/drpc/drpcserver.(*Server).handleRPC:122\n\tstorj.io/drpc/drpcserver.(*Server).ServeOne:66\n\tstorj.io/drpc/drpcserver.(*Server).Serve.func2:112\n\tstorj.io/drpc/drpcctx.(*Tracker).track:52", "Size": 0}

2022-03-29T19:38:34.481Z        ERROR   piecestore      upload failed   {"Piece ID": "YYRUPECCQZWB43UA75PFHZUMD4VKRDVNISO35ILVW4OHFPT4SDSA", "Satellite ID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Action": "PUT_REPAIR", "error": "order: grace period passed for order limit", "errorVerbose": "order: grace period passed for order limit\n\tstorj.io/storj/storagenode/orders.(*FileStore).BeginEnqueue:86\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).beginSaveOrder:696\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).Upload:318\n\tstorj.io/common/pb.DRPCPiecestoreDescription.Method.func1:220\n\tstorj.io/drpc/drpcmux.(*Mux).HandleRPC:33\n\tstorj.io/common/rpc/rpctracing.(*Handler).HandleRPC:58\n\tstorj.io/drpc/drpcserver.(*Server).handleRPC:122\n\tstorj.io/drpc/drpcserver.(*Server).ServeOne:66\n\tstorj.io/drpc/drpcserver.(*Server).Serve.func2:112\n\tstorj.io/drpc/drpcctx.(*Tracker).track:52", "Size": 0}
2022-03-29T19:38:34.490Z        INFO    piecestore      uploaded        {"Piece ID": "VLXRZV3WM2ECCKQ5HPOXFWZZLBDQQA42NLABHZKESQ3EXH5EVPTQ", "Satellite ID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Action": "PUT", "Size": 181504}

2022-03-29T19:38:21.873Z        ERROR   piecestore      upload failed   {"Piece ID": "NG2OCAJ4BTQ5SJ356TO6SICBTRKIYZMZUKI4VHHASFIQOYEABXLQ", "Satellite ID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Action": "PUT", "error": "order: grace period passed for order limit", "errorVerbose": "order: grace period passed for order limit\n\tstorj.io/storj/storagenode/orders.(*FileStore).BeginEnqueue:86\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).beginSaveOrder:696\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).Upload:318\n\tstorj.io/common/pb.DRPCPiecestoreDescription.Method.func1:220\n\tstorj.io/drpc/drpcmux.(*Mux).HandleRPC:33\n\tstorj.io/common/rpc/rpctracing.(*Handler).HandleRPC:58\n\tstorj.io/drpc/drpcserver.(*Server).handleRPC:122\n\tstorj.io/drpc/drpcserver.(*Server).ServeOne:66\n\tstorj.io/drpc/drpcserver.(*Server).Serve.func2:112\n\tstorj.io/drpc/drpcctx.(*Tracker).track:52", "Size": 0}
2022-03-29T19:38:21.886Z        INFO    piecestore      uploaded        {"Piece ID": "S7CXQCFJL6XL3REFAKSPTM3Y353GAXJXDBSLR3EOTEOA2I2L5EJA", "Satellite ID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Action": "PUT", "Size": 2048}

I have not redirected any logs to any file, I check the logs with docker logs <NODE_ID>

Otherwise, I can see that my statistic is not particularly good, having in mind the offline status - but is this statistic for my network or for the node - since if it is only for this node, I may consider starting with a new identity, so I can prove the node resilient and stable.

Here is a reference to what I’m referring:

Kind regards,

This suggests that you have clocks out of sync issue. Please, sync your clocks.

If your node is offline - you should fix that. See

And perhaps it’s also related to a wrong time.

Hey Alexey,

I will definitely pass through the given article - long story short, I got disqualified, so I started again for I don’t know which time like this:

PS C:\Users\Rumen> docker run --rm -e SETUP="true" --mount type=bind,source="C:\Users\Rumen\Desktop\identity-hosts\storagenode",destination=/app/identity --mount type=bind,source="F:\node1",destination=/app/config --name node1 storjlabs/storagenode:latest

Unfortunately, I’m getting the following:

docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /run/desktop/mnt/host/f/node1.

Why is that being shown as an error, when I have specified the correct path to my configuration, I also checked using WSL, I do not have such path.

Any idea why this is not working for me?

I’m running this on Windows 10, Docker Application GUI - running the command under PowerShell 7 as admin.

Does drive “F:” exist?
Please, do not use admin to run docker containers, use your usual user instead.
And also - have you enabled the wsl in the docker desktop?
If so, try to restart the WSL (run from PowerShell as a usual user):

wsl --shutdown

Docker desktop should offer you to restart the docker, please agree. It will start the WSL and restart the docker daemon.

Hey Alexey,

Thank you for the provided information.

Yes, WSL is enabled here:

I would like to mention that I generated a new identity and did the whole process again, not sure if my previous identity was corrupted or anything.

Got the WSL restart, ran the command - container has been started, it works - at least for now.

Here are the last lines of the log output:

2022-04-07T13:37:21.980Z        INFO    db      database does not exist {"database": "info"}
2022-04-07T13:37:21.981Z        INFO    db      database does not exist {"database": "bandwidth"}
2022-04-07T13:37:21.982Z        INFO    db      database does not exist {"database": "orders"}
2022-04-07T13:37:21.982Z        INFO    db      database does not exist {"database": "piece_expiration"}
2022-04-07T13:37:21.983Z        INFO    db      database does not exist {"database": "pieceinfo"}
2022-04-07T13:37:21.984Z        INFO    db      database does not exist {"database": "piece_spaced_used"}
2022-04-07T13:37:21.984Z        INFO    db      database does not exist {"database": "reputation"}
2022-04-07T13:37:21.985Z        INFO    db      database does not exist {"database": "storage_usage"}
2022-04-07T13:37:21.986Z        INFO    db      database does not exist {"database": "used_serial"}
2022-04-07T13:37:21.986Z        INFO    db      database does not exist {"database": "satellites"}
2022-04-07T13:37:21.987Z        INFO    db      database does not exist {"database": "notifications"}
2022-04-07T13:37:21.987Z        INFO    db      database does not exist {"database": "heldamount"}
2022-04-07T13:37:21.988Z        INFO    db      database does not exist {"database": "pricing"}
2022-04-07T13:37:21.989Z        INFO    db      database does not exist {"database": "secret"}
2022-04-07T13:37:22.410Z        INFO    Current binary version  {"Service": "storagenode", "Version": "v1.52.2"}
2022-04-07T13:37:22.410Z        INFO    Version is up to date   {"Service": "storagenode"}
2022-04-07T13:37:22.427Z        INFO    Current binary version  {"Service": "storagenode-updater", "Version": "v1.52.2"}
2022-04-07T13:37:22.427Z        INFO    Version is up to date   {"Service": "storagenode-updater"}
2022-04-07 13:37:23,429 INFO success: processes entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2022-04-07 13:37:23,429 INFO success: storagenode entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2022-04-07 13:37:23,429 INFO success: storagenode-updater entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2022-04-07T13:37:34.124Z        INFO    Telemetry enabled       {"instance ID": "1goJaKCBNoXAcojEDrXqQDm4NJYRGEaPjjDadysXZSeT3syJJH"}

Should I be concerned about these database messages?

I really appreciate your time into looking this matter!

Since you started with a clean storage and new identity - the storagenode created all required databases.

Hey Alexey,

Roger that.

As of now, everything seems exceptionally normal - hopefully no nodes will ever go down in regard to what I experienced previously. You can mark this case/ticket as closed, no further assistance at least for now is needed.

You have been a huge help and I do appreciate it as always!

Kind regards,
Rumen A.

2 Likes

A post was split to a new topic: It seems like the node restarts on itself