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

[Cancelor]

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.

[beli]

FYI

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

[anon27637763]

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.

[beli]

The docker “machine” is not running. Is exits instantly after the database-error. lsof is empty

[anon27637763]

I’m in learning mode on this thread…

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

Docker and Kubernetes — root vs. privileged

…

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

[beli]

QNAP has a “admin” as UID-0-root-equivalent

Same content - another name

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

[immiq]

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

[jfnz]

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).