Disqualified - what happened?

I checked my config.yaml and it appears that the storage.path was changed.

My Storj data folder shows last access of May 8 and after correcting the config.yaml file, most DBs are updated with today’s date. I didn’t change anything. My node has been online since the alpha and I updated my node from docker to Windows back in November with no issues.

I only have several disqualification emails from various locations but not all of them.

Do I need to start again?

Seems contradict each other.

Now you have two locations with data. Your node will be disqualified on all satellites soon.
It is hard to say, which path was a right one.

If you migrated from the docker, the right path should contain the storage as a end folder.

When I opened the config.yaml, it was pointed at a non existent path on my system.

The location of the data was showing date codes of May 8. I corrected the path in the file after discovering the wrong path.

I mean to say that I did not change the config file to point it to the non existent path.

Then your node would not start and should be offline.
If it was online, then it’s stored data somewhere. And this path was correct, otherwise it will be disqualified months ago.
Please, show the result of the command (Powershell):

sls "storage.path" "C:\Program Files\Storj\Storage Node\config.yaml"

It shows online now but obviously it is disqualified. Is there a point in troubleshooting or should I just start a new node?

Requested PS output: (This is the correct path)

PS C:\Users\Admin> sls “storage.path” “C:\Program Files\Storj\Storage Node\config.yaml”

C:\Program Files\Storj\Storage Node\config.yaml:164:storage.path: E:\storj\storage\

You should start over, but we should figure out, why is it happened to do not repeat this mistake again.

Please, show the result of the command (Powershell):

ls E:\storj

As requested:

And this one

ls E:\storj\storage

P.S. I want to check is there duplicated storage locations

Seems there is no other storage locations at least on that drive.

Please, search for “GET_AUDIT” and “failed” in the log (Powershell):

sls "GET_AUDIT" "C:\Program Files\Storj\Storage Node\storagenode.log" | sls "failed"

Output is too long to put in the forum.


C:\Program Files\Storj\Storage Node\storagenode.log:6915590:2020-05-08T02:11:27.391-0400    ERROR   piecestore  download
"12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Action": "GET_AUDIT", "error": "usedserialsdb error: database
is locked", ...
C:\Program Files\Storj\Storage Node\storagenode.log:6916010:2020-05-16T20:55:19.371-0400 

Did you run the node between May 8th and May 16th ?

If so, did you run the node with the incorrect path for those 8 days?

I assume it was running and I do assume the path was incorrect since May 8 as that was the latest date in the data folder.

Well… I guess your node running the incorrect path for a week collected data pieces which are now being audited after you corrected the path… which definitely leads to DQ since those data pieces do not exist in the corrected path.

Docker node on Mac OS, node not suspended or DQd but I can’t figure out why this happened Screen Shot 2020-08-21 at 12.00.53 Screen Shot 2020-08-21 at 11.52.03 Screen Shot 2020-08-21 at 11.52.36 open to advise or suggestion

you have 1 not successfull audit, data lost or something like that

so one failed audit takes me from 100% to 98.2%, does that mean that it will never be at 100% again

it will, because this one will take less and less efect during the time.

You should look for all failed audits, remove the last piped command and see what you get. I think “open” was even based on old log terminology, but it definitely won’t show you all errors either way.

I don’t understand “remove the last piped command” and a search for failed audits reported 0 failed audits Screen Shot 2020-08-21 at 11.52.03