I had about a week or more of downtime recently, and I’m trying to get back up and running. I migrated my data from one filesystem to another (kept the same mount point at the end), and when I try to start my docker container I get errors saying the disk doesn’t exist. Error log here since I “can’t post more than 2 links”
I realize my node might have been disqualified but I’m trying to figure out how to come back online with the data I have, or if I need to start again from scratch, how do I do that?
I am on Docker on Ubuntu Linux. My device is correctly mounted- everything else is working fine. I’m wondering if there was some error maybe permissions changed or something got corrupted during the move?
I think based on the error, you’ll need to convince us that the drive is properly mounted. Are you able to show the output of an ls -al at the location that’s bind mounted to /app/config in the container?
This is recommended for the edge case where you could start up the node but the volume isn’t mounted (i.e. directory doesn’t exist on the host). When using volumes without bind (i.e. equivalent to -v in a docker run command), if the directory doesn’t exist on the host, Docker will create an empty one. This could lead to a quick DQ because Storj would see that a bunch of data is missing and you’ll fail all audits. Believe me, I know, I lost my first node this way. Storj has recently made some improvements to help circumvent this disaster scenario.
With a bind mount, Docker will fail to start the container if the host directory doesn’t exist. It’s an easy change in your compose file and I’d recommend following the format specified by @deathlessdd with your source directories /opt/docker/storj and data/Storj. Having said that, it’s important to understand that that with a Docker bind mount, the directory has to exist, but if that directory itself is a mount point for a drive that you’re storing Storj data on, if it’s not mounted, Docker will still start the container with the existing empty directory. Ideally, to use your path as an example, your drive is actually mounted at /data and the directory /data/Storj would not exist if the drive wasn’t mounted. This would provide the protection intended by the bind mount if /data was not mounted.
In any case, looks like the disk is there. Just as another sanity check, can you verify that ls -al storage shows a bunch of .db files and some directories?
looks like docker does not have permission on the data folder from your output of “sudo ls -al /data/Storj/storage/” only root user has full permission of read and write.
and I think docker does not run as root. you may need to run “sudo chmod -R 777 /data/StorJ/storage/” to allow all user read and write access to storj data folder.