Thank you. My HDD is correctly connected. I’ve done a chkdsk and it’s perfect, and SMART is OK.
You should have failed audits in the log, what do the log entries specify as the reason?
How I can see it? I’ve find some scripts and PS commands, but nothing works. I have Windows 10 and Docker node
My guess is that Docker lost the mount to the drive at some point. Since the Saltlake sat (1wF…) has an okay score, it was probably before that satellite came online, around February 12 I think. Unfortunately, and it does suck, there is nothing to be done. My suggestion would be to start over with the windows GUI installation this time and avoid docker all together. You will need to create a new identity.
Id recommend switching away from docker as its known to cause issues running a node in windows, With your next setup I would just use windows GUI is much more stable then docker is.
Also theres no recovering from it once you get DQed thats it you gotta start over.
Did you still use the -v mounting options in the docker run command? This could lead to the mount not initiating properly and the node starting with a temporary volume instead. The result of this is missing data and failing audits.
Btw, the latest version of the earnings calculator will name the -UNKNOWN- satellite correctly.
I’ve reviewed my mounting…
docker run -d --restart unless-stopped -p 28967:28967 -p 14002:14002 -e WALLET=“0xxxxx” -e EMAIL="firstname.lastname@example.org" -e ADDRESS=“xxxxx.ddns.net:28967” -e BANDWIDTH=“200TB” -e STORAGE=“4TB” -v “C:\storj\storagenode\”:/app/identity -v “D:\storj\StorjData\”:/app/config --name storagenode storjlabs/storagenode:alpha
and yes, there is a “-v”. But it is there from long time ago.
PS: I still persist because I need to know what ocurred to prevent a new problem. It’s frustrating to delete all and start again after 8 months.
Then I’d say there’s your issue. -v is not used in a very long time. You have to use -mount. But someone from the team please explain better.
This is my command:
sudo docker run -d --restart always -p 28967:28967
-e BANDWIDTH="50TB "
–name storagenode storjlabs/storagenode:beta
Previous versions of the
docker runcommand that used the
-vrather than the
--mountoption will not work properly. Copy the updated command below.
You should not use
-v, with this option if your data folder is not mounted for any reason the docker will create an empty volume for you and will store customers’ data in the container instead of the disk.
Your node start failing audits for previous data, which is not available for that container.
When you remove such container (for upgrade for example), it will be removed with customers data and your node will start to fail audits for data being removed.
This is why we replaced the documentation 8 months ago: https://documentation.storj.io/setup/cli/storage-node#running-the-storage-node
In addition you should use the
beta tag instead of
alpha, it’s in the updated
docker run command too.
This warning has been sent to all SNO via email back in August 2019 and then remain in any update email until at least December 2019:
Important note about mounting your node hard drive.
In the early stages of our alpha, we had incorrect instructions for how to mount your node in the Explorer Setup Guide on Github. If you’re an affected user, you’ll see
docker run storagenodecommand to point to the location of their identity and storage folders. Please update your
docker runcommand using these instructions.
Thank you guys.
I’m sure I changed this “-v” to “–mount” when I received the warning mail, because I remember it. But in any step (when I changed my wallet for example) I copied an old command to registrate again the container putting again “-v”.
It happens, but I think you found the most likely culprit for the loss of data. The upside is that there is now a windows GUI install which gets rid of all issues that come with docker on windows. It is a far better option and should be much more stable for you. So I hope you’ll give that a try!
Recently I got disqualified on one node “eu1.storj.io:7777” due to a HW problem with 1 hdd on my node and after I fixed it, there was a storm here in Bulgaria with floods and there was a power outage for few hours. It appears that after the power outage my node powered up automatically and the Storage node service started automatically, but I wasn’t finished restoring all the data from the damaged hdd. Therefor I received bad audits probably for missing data. That happened for few hours, not more than 8 I think. I think it is not fair. I was on the network more than an year and I get disqulified for few hours … Can anyone advise me if I can get back in after few months? How can I reach someone from the support for example. Because it is totally unfair. There was Tornado in the Czeh republic, we had thunderstorms and flood in Bulgaria, people died and StorJ doesn’t care and disqualifies people.
Disqualifications are permanent. You can’t “get back after few months”.
Climate change is real. I am sorry for the loss of life and property in your country. But such incidents are covered under Force Majeure.
d. Force Majeure.
Except for payment obligations, neither Company nor Customer will be liable for delayed or inadequate performance of its obligations hereunder to the extent caused by a condition that is beyond the party’s reasonable control, including but not limited to natural disaster, civil disturbance, acts of terrorism or war, labor conditions, governmental actions, interruption or failure of the Internet or any utility service, and denial of service attacks (each a “Force Majeure Event”). The party affected shall be relieved from its applicable obligations as long as the Force Majeure Event lasts and hinders the performance of said obligations. The party affected shall promptly notify the other party and make reasonable efforts to mitigate the effects of the Force Majeure Event with reasonable dispatch; if Company is the party affected, this requirement can be satisfied by notice posted on its website.
Whenever you have HW issue you should probably disconnect from the internet till you fix your issue. This way your node would not go online. Your online score will get affected but you can recover it, provided you don’t stay offline for too long.
Great advice, I will keep that in mind for the future and will keep the node’s LAN unplugged until everything is fully fixed. Thanks.
However, these sentences got me thinking “The party affected shall be relieved from its applicable obligations as long as the Force Majeure Event lasts and hinders the performance of said obligations. The party affected shall promptly notify the other party and make reasonable efforts to mitigate the effects of the Force Majeure Event with reasonable dispatch; if Company is the party affected, this requirement can be satisfied by notice posted on its website.”
I read it 3 times. I think it says that in disasters like the one that I explained I should have informed StorJ. But how do I do that? The only working thing at that moment at home was my cell phone with 20 percent charge. And Yes, I had mobile connection 3g/4g with few MB left. But I ask again the same quesiton. How do you reach the StorJ support? Maybe if I knew their contact, I could have written them an e-mail, so that they could have stopped any connections from my node until the outage was gone and my node was totally up and running?
…Sorry the node died I agree the DQ is/can be very fast ! a small error, resulting in failed audits over a few hours and even the most long term node is banned. I get the network is resilient, but it would be nice if there was a software limiter, so to not instantly DQ a node that is having a bad week
In such disasters your first priority is taking care of yourself and your loved ones. Node being offline is an indication/signal/notification to the satellite that something is wrong. You can contact support at support.storj.io but you are not expected to do so just to inform that your node is disqualified. In case you want to know why it was disqualified then you should definitely contact support.
No, it did not die.
The hdd started having a lot of bad sectors. I managed to copy most of the data on few other hdds. And i had another 2TB hdd that I used to replace the one that started having bad sectors. I did that. But unfortunately, while I was copying back the data, this storm unleashed(I was copying over 12 hours, it is more than 2TB of data) and my electricity got cut off. It was in the evening. So I went to sleep. And when I woke up I was already disqualified, because at some point during the night the power was restored. The node booted up and Storj service started, but because I did not manage to copy all the data I started receiving the bad audits. And in a couple of hours I got disqualified. I am very dissapointed, because I did not have any chance to do anything. But for the future issues I will definetly unplug the LAN before I am 100% sure that everything is working properly.
Oof, that really sucks. I’m sorry you had to deal with all that. I hope you and your family are all fine.
As for the node, disqualification is unfortunately permanent. The reason for this is that the satellite can’t know whether your node is being recovered and in most cases it can be sure it’s dealing with a node that is losing data. If they don’t take action fast in those scenarios, they risk losing customer data. A lot of safeguards have already been put in place, the node for example now tests whether the data location is available and the data is actually owner by the identity being used. Your scenario where this validation file exists, but other files don’t is very rare. You can contact support at support.storj.io (submit a request link at the top right), but you shouldn’t expect them to be able to recover your node. That doesn’t mean you can’t get back in though, it only means you will have to start over with a new identity.
The problem is that this clause waives liability for the customer or the company, not for the node operator. This only addresses the relationship between Storj Labs and their customers. I’m not a lawyer, but I don’t think it applies here unfortunately. For node operators, the following terms and conditions apply. And predictably Storj Labs covers their own liability, but not the node operators.
- 13.2. LIMITATION OF LIABILITY . COMPANY SHALL NOT BE LIABLE FOR ANY INCIDENTAL, CONSEQUENTIAL, PUNITIVE, SPECIAL, INDIRECT, OR EXEMPLARY DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS, REVENUE, DATA, OR DATA USE, OR DAMAGE TO BUSINESS) HOWEVER CAUSED, WHETHER BY BREACH OF WARRANTY, BREACH OF CONTRACT, IN TORT (INCLUDING NEGLIGENCE) OR ANY OTHER LEGAL OR EQUITABLE CAUSE OF ACTION EVEN PREVIOUSLY ADVISED OF SUCH DAMAGES IN ADVANCE OR IF SUCH DAMAGES WERE FORESEEABLE, AND IN NO EVENT WILL COMPANY’S TOTAL AGGREGATE LIABILITY ARISING FROM OR RELATING TO THIS AGREEMENT EXCEED US $25.
I don’t mind that. I just want a chance to recover.