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

I woke up to my node giving me the same error. Any tips to get it back online.

2020-08-04T15:23:51.445Z	INFO	Operator email	{"Address": "##REDACTED##"}

2020-08-04T15:23:51.445Z	INFO	Operator wallet	{"Address": "##REDACTED##"}

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

	storj.io/storj/storagenode/storagenodedb.(*DB).openDatabase:272

	storj.io/storj/storagenode/storagenodedb.(*DB).openDatabases:187

	storj.io/storj/storagenode/storagenodedb.New:174

	main.cmdRun:150

	storj.io/private/process.cleanup.func1.4:353

	storj.io/private/process.cleanup.func1:371

	github.com/spf13/cobra.(*Command).execute:840

	github.com/spf13/cobra.(*Command).ExecuteC:945

	github.com/spf13/cobra.(*Command).Execute:885

	storj.io/private/process.ExecWithCustomConfig:88

	storj.io/private/process.ExecCustomDebug:70

	main.main:323

	runtime.main:203

This is the content of the data/storage folder.

bandwidth.db*
blobs/
garbage/
heldamount.db*
info.db*
notifications.db*
orders.db*
piece_expiration.db*
piece_spaced_used.db*
pieceinfo.db*
pricing.db*
reputation.db*
satellites.db*
storage_usage.db*
temp/
trash/
used_serial.db*

Are you running a docker container?

https://forum.storj.io/t/error-starting-master-database-operation-not-permitted-after-update-on-qnap-nas/8449/14

Yes, i am running docker, and its actually 2/7 nodes that are showing the same error. I am suspecting it is related to the most recent update.

Is it QNAP or what is your OS/hardware?

Please, show result of the command (replace the data/storage to your actual path):

ls -l data/storage

And how you run the docker run command? With sudo?

Is a QNAP device.

-rwxrwxrwx    1 admin    administ   3956736 Aug  4 00:32 bandwidth.db*
drwxrwxrwx    8 admin    administ      4096 May  8 22:59 blobs/
drwxrwxrwx    2 admin    administ      4096 Aug  3 11:12 garbage/
-rwxrwxrwx    1 admin    administ     32768 Aug  4 00:32 heldamount.db*
-rwxrwxrwx    1 admin    administ     16384 Aug  4 00:32 info.db*
-rwxrwxrwx    1 admin    administ     24576 Aug  4 00:32 notifications.db*
-rwxrwxrwx    1 admin    administ 210206720 Aug  4 00:32 orders.db*
-rwxrwxrwx    1 admin    administ     36864 Aug  4 00:32 piece_expiration.db*
-rwxrwxrwx    1 admin    administ     24576 Aug  4 00:32 piece_spaced_used.db*
-rwxrwxrwx    1 admin    administ     24576 Aug  4 00:32 pieceinfo.db*
-rwxrwxrwx    1 admin    administ     24576 Aug  4 00:32 pricing.db*
-rwxrwxrwx    1 admin    administ     24576 Aug  4 00:32 reputation.db*
-rwxrwxrwx    1 admin    administ     32768 Aug  4 00:32 satellites.db*
-rwxrwxrwx    1 admin    administ    106496 Aug  4 00:32 storage_usage.db*
drwxrwxrwx    2 admin    administ      4096 Aug  1 12:49 temp/
drwxrwxrwx    8 admin    administ      4096 May 17 03:30 trash/
-rwxrwxrwx    1 admin    administ  48787456 Aug  4 00:32 used_serial.db*

I ran the exact command described here. https://documentation.storj.io/setup/cli/storage-node

The two nodes on the QNAP device have been operational for several months now without any issues.

Do you run it with sudo or without?

I ran it without sudo

What the command say:

echo $USER

It returns the user admin

I am seeing the same issue on my storj node. Error messages are same as start of this thread.
I am running it as a container as root on a Linux SBC (pine64). It was running without any issues previously. I suspect it might be related to a recent update (?).
I have been running the container as well as the watchtower container.
Appreciate any assistance.

1 Like

Same issue on a Rock64. Container as root, stopped working after the update. Permissions are correct.

Same here, on qnap there you have no “root” :frowning:

4 posts were merged into an existing topic: Error starting master database on storagenode: stoage node database error: file is not a database

Hi @bovcan
Your hint guided me to search the “error” in the “docker-universe” as QNAP is not more the only intersection.

Both of my Storagenode are now up and running. I just added " --privileged " to the run-command.

Seems really a permission issue. Strange is here that it seem to happen only after upgrade to actual version without touching any docker/qnap-components.

I also tested if the storagenode is running after migration to DB43 without --privileged. => No!

2 Likes

The stack trace is identical.

Adding the --privileged flag to the docker run command appears to have resolved my issue.
Thanks!

I will be concerned if we need to run the container with privileges after updating to the latest version. I can’t think of one good reason the storagenode would need access to the host.

@Alexey any updates ?

No. I have no information from the team why you should specify --priveleged now.
It’s not required on Windows and Raspberry Pi as far as I aware.