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"
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"
C:\Program Files\Storj\Storage Node\storagenode.log:6915590:2020-05-08T02:11:27.391-0400 ERROR piecestore download
failed {"Piece ID": "WSKSMLUXHX5GS3XNHMCKSRGZKM4KIJNBYNGIDSWENXQXO42VRO7A", "Satellite ID":
"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 
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