electrs: Failed to create RocksDB directory

Hi,

I’ve built the docker image successfully and tried to run the container/server with:

docker run --network host \
           --volume /mnt/clouddrive/.bitcoin:/home/user/.bitcoin:ro \
           --volume /mnt/clouddrive/electrs:/home/user \
           --rm -i -t electrs-app \
           electrs -vvvv --timestamp --db-dir /home/user/db

Here is the output with RUST_BACKTRACE=full:

Config { log: StdErrLog { verbosity: Trace, quiet: false, show_level: true, timestamp: Millisecond, modules: [], writer: "stderr", color_choice: Auto }, network_type: bitcoin, db_path: "/home/user/db/mainnet", daemon_dir: "/home/user/.bitcoin", daemon_rpc_addr: V4(127.0.0.1:8332), electrum_rpc_addr: V4(127.0.0.1:50001), monitoring_addr: V4(127.0.0.1:4224), jsonrpc_import: false, index_batch_size: 100, bulk_index_threads: 6, tx_cache_size: 10485760, txid_limit: 100, server_banner: "Welcome to electrs 0.8.3 (Electrum Rust Server)!", blocktxids_cache_size: 10485760 }
2020-05-21T22:12:28.280+00:00 - DEBUG - Server listening on 127.0.0.1:4224
2020-05-21T22:12:28.285+00:00 - DEBUG - Running accept thread
2020-05-21T22:12:29.760+00:00 - INFO - NetworkInfo { version: 190001, subversion: "/Satoshi:0.19.0.1/", relayfee: 0.00001 }
2020-05-21T22:12:31.521+00:00 - INFO - BlockchainInfo { chain: "main", blocks: 631229, headers: 631229, verificationprogress: 0.99999647717456, bestblockhash: "00000000000000000011d5c21b0125664be4052e10b95e35ef1bf375244d48a7", pruned: false, initialblockdownload: false }
2020-05-21T22:12:31.523+00:00 - DEBUG - opening DB at "/home/user/db/mainnet"
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: "Failed to create RocksDB directory: `Os { code: 13, kind: PermissionDenied, message: \"Permission denied\" }`." }', src/store.rs:60:17
stack backtrace:
   0:       0x5569a06298 - backtrace::backtrace::libunwind::trace::h88e4781b95be5e7d
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1:       0x5569a06298 - backtrace::backtrace::trace_unsynchronized::h27424f3324e761be
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2:       0x5569a06298 - std::sys_common::backtrace::_print_fmt::h7d3510b3a4048fe7
                               at src/libstd/sys_common/backtrace.rs:77
   3:       0x5569a06298 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc9d57e2bd1e53ca8
                               at src/libstd/sys_common/backtrace.rs:59
   4:       0x556987f538 - core::fmt::write::h3a82d9a133640e63
                               at src/libcore/fmt/mod.rs:1052
   5:       0x5569a05a48 - std::io::Write::write_fmt::h0d8caa20275259fe
                               at src/libstd/io/mod.rs:1426
   6:       0x5569a05688 - std::sys_common::backtrace::_print::ha706fb52b493e47b
                               at src/libstd/sys_common/backtrace.rs:62
   7:       0x5569a05688 - std::sys_common::backtrace::print::h62d24dbbbcdb47e7
                               at src/libstd/sys_common/backtrace.rs:49
   8:       0x5569a05688 - std::panicking::default_hook::{{closure}}::heba3e973eafbb1d9
                               at src/libstd/panicking.rs:204
   9:       0x5569a04df4 - std::panicking::default_hook::he515c32b9ced0a2d
                               at src/libstd/panicking.rs:224
  10:       0x5569a04df4 - std::panicking::rust_panic_with_hook::h580ddde2c8bb727f
                               at src/libstd/panicking.rs:472
  11:       0x5569a04a98 - rust_begin_unwind
                               at src/libstd/panicking.rs:380
  12:       0x556987d704 - core::panicking::panic_fmt::hf152853fda7ac566
                               at src/libcore/panicking.rs:85
  13:       0x5569882be0 - core::option::expect_none_failed::h6b4d39870d82acf6
                               at src/libcore/option.rs:1199
  14:       0x5569896bbc - electrs::main::h3aee48bad518ed0d
  15:       0x556988bf1c - std::rt::lang_start::{{closure}}::h52a53a942887a108
  16:       0x556988f0a0 - main
  17:       0x7f9b505d24 - __libc_start_main
  18:       0x5569854160 - <unknown>

I see that /mnt/clouddrive/electrs exists and has empty .bitcoin dir inside. It’s owned by root with 755 permissions.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 18 (10 by maintainers)

Most upvoted comments

He means don’t make it publicly accessible at all.

So if you want it accessible over the internet, put some auth in front like an SSH tunnel/VPN/Tor etc.

electrs was written for the personal use-case (i.e. assuming “non-malicious” users). It was not meant to handle denial-of-service attacks, and its performance may suffer significantly if there are many concurrent connected clients. I wouldn’t recommend exposing it to the world without any authentication.

When you say it stopped working, what exactly happened? The log output stopped and it returned to your host shell prompt?

Exactly like that and it’s definitely memory. Every time it stopped, both memory and cpu peaked. One time even bticoind crashed.

Instead of trying out the --jsonrpc-import and letting Odroid create the indexed db on it’s HDD which would take ages, I’ve ran the container/server on my desktop machine (AMD R5 3600, 16GB RAM, SSD). I mounted a samba share to the .bitcoin directory on Odroid and used it as the .bitcoin volume, while the other volume was a db directory on SSD. It took around 2.5 hours to create the indexed db of 61.9GB. I then copied the db to Odroid HDD and ran the container/server on Odroid with --jsonrpc-import. So far it is up and running for 11 hours.

I’ll try the suggested usage (without --jsonrpc-import), but first I want to make sure it runs fine as it is. Also, the next step is to set up SSL connection using NGINX as an SSL endpoint following the instructions from the man page.

Thanks both @lukechilds and @Kixunil for helping me out.

Got it. I’ve set up Tor hidden service and disabled port forwarding, so it’s accessible outside my network only over Tor.

It’s worth noting that on the other hand, it’ much more performant than ElectrumX for the personal use case. 😃

@lukechilds one doesn’t have to study config spec. electrs supports --help and has a man page too. 😃

@Kixunil Docker is great at many things, but handling permissions is definitely not one of them!

From the Dockerfile:

RUN adduser --disabled-login --system --shell /bin/false --uid 1000 user

USER user

So the electrs process inside the container is running with uid 1000 which doesn’t have permission on the host to write to that dir.

@OvoNemaSmisla can you try running:

$ sudo chown -r 1000:1000 /mnt/clouddrive/electrs

And then run the container again?

Looks like something is messed up with the docker image. Isn’t docker supposed to deal with these kinds of things? I never used it, but people tried to sell it to me as a magic solution to these problems. 😉