Error starting master database on storagenode: storage node database error: unable to open database file: operation not permitted

Complete shot in the dark here but I wonder if this has any bearing > https://serverfault.com/questions/364677/why-is-chmod-r-777-destructive

sudo , sendmail , and a host of others simply will not start any more.

The mode  `777`  is actually  ***`0`*** `777` . 
Among the things in that leading digit are the  `setuid`  and  `setgid`  bits.
Most programs which are setuid/setgid have that bit set because
they must run with certain privileges. They're broken now.

FYI

i didn’t touch any permissions. My permissions go to 600 (rw-) for files and 700 (rwx) for directories.

1 Like

It may be a good idea to post what files are being used in each scenario…

  1. Run the docker command without the privileged option… and check the files used

    lsof -c storagenode

  2. Run the docker command with the privileged option… and check again

    lsof -c storagenode

My guess is that the 1.9.5 requires privileged access to RAM to run the databases.

No one should be modifying file permissions… and especially not to 777 … please don’t do that.

The docker ā€œmachineā€ is not running. Is exits instantly after the database-error. lsof is empty

I’m in learning mode on this thread…

Here’s a post I found on the differences between docker --privileged and sudo docker run

…

In an earlier post, someone indicated that docker was not sudo-ed And someone also indicated that QNAP doesn’t have root…

QNAP must have a root user. I don’t know my way around QNAP, but I do know my way around GNU/Linux and various other *nix systems. Root is just another name for ā€œsuperuserā€. All *nix OSes have one… However, QNAP might not have set a root password and might have the root account mostly disabled…

Here’s a QNAP forum post on sudo:

https://forum.qnap.com/viewtopic.php?t=132718

It seems like this problem is limited to QNAP. I’m running Debian and Docker and have not seen this problem. I also set the container with ā€œsudo docker runā€ …

In any case, for anyone reading this thread:

Please do not change any file permissions to 777

and… apparently… --privileged is not directly equated to sudo docker run

QNAP has a ā€œadminā€ as UID-0-root-equivalent

Same content - another name :wink:

/etc/passwd
admin:x:0:0:administrator:/share/homes/admin:/bin/sh

The question is what changed? It was working fine for many months until the last update.

2 posts were merged into an existing topic: Ordersdb error: database is locked

Same issue here. 1 out of 2 of my Storj nodes running on QNAP now fails to start. Issue started after what looked like watchtower pulled an update.

Fixed it with the ā€œā€“priviledgedā€ flag, but also not too keen on keeping it that way given any potential security concerns.

In case it helps anyone, this is the command I use to provision the container (just delete your old one, the config and node data is retained):

docker run -d --restart unless-stopped --stop-timeout 300 --privileged \
-p 28967:28967 \
-p 14002:14002 \
-e WALLET="<your wallet id>" \
-e EMAIL="<your email address>" \
-e ADDRESS="<your dynamic dns name>:28967" \
-e STORAGE="2TB" \
--mount type=bind,source="/share/CACHEDEV1_DATA/storj/identity/",destination=/app/identity \
--mount type=bind,source="/share/CACHEDEV1_DATA/storj/data/",destination=/app/config \
--name storagenode storjlabs/storagenode:latest

Forward TCP/28967 toward your Storj node but don’t forward TCP/14002 (the latter should generally only be accessible on your LAN only for you to view the status).