Error: nippy jar error: 拒绝访问。 (os error 5)

[MiraWells]

Describe the bug

Error: nippy jar error: 拒绝访问。 (os error 5)

Steps to reproduce

1 run reth on windows 2 see the bug

Node logs

2024-07-23T23:12:53.971245Z  INFO reth::cli: Initialized tracing, debug log directory: C:\Users\10200\AppData\Local\reth\logs\mainnet
2024-07-23T23:12:53.974415Z  INFO reth::cli: Starting reth version="1.0.3 (6ce7c9e3)"
2024-07-23T23:12:54.175145Z  INFO reth::cli: Opening database path=".\\db"
2024-07-23T23:12:54.196656Z DEBUG storage::db::mdbx: Commit total_duration=309.9µs commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 1, audit: 0, write: 7, sync: 9, ending: 0, whole: 19, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 1, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 2, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 2, self_counter: 3, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 1 } })) is_read_only=false
2024-07-23T23:12:54.203920Z  INFO reth::cli: Configuration loaded path=".\\reth.toml"
2024-07-23T23:12:54.210639Z  INFO reth::cli: Verifying storage consistency.
2024-07-23T23:12:54.218487Z ERROR reth::cli: shutting down due to error

Platform(s)

Windows (x86)

What version/commit are you on?

reth Version: 1.0.3
Commit SHA: 6ce7c9e
Build Timestamp: 2024-07-23T23:07:46.325152100Z
Build Features: jemalloc
Build Profile: debug

What database version are you on?

2024-07-23T23:20:16.474702Z INFO Initialized tracing, debug log directory: C:\Users\10200\AppData\Local\reth\logs\mainnet
Current database version: 2
Local database version: 2

Which chain / network are you on?

mainnet

What type of node are you running?

Archive (default)

What prune config do you use, if any?

[stages.prune]
commit_threshold = 1000000

If you've built Reth from source, provide the full command you used

cargo build

Code of Conduct

• I agree to follow the Code of Conduct

### Tasks

[onbjerg]

This is an access denied error, please check that the user running the node has R/W access to your node's data directory.

[MiraWells]

I am double checked that the user running the node has R/W access to your node's data directory.

[MiraWells]

I confirm that there are no issues with read and write permissions. If you have Windows, you can run it and see what problem I'm referring to.

[saguillo2000]

I'm facing the same issue: Error: nippy jar error: Acceso denegado. (os error 5). This is with the tutorial hello_world of exex

[saguillo2000]

@lucyzhang314 I solved it by running reth in WSL (Ubuntu 20.04), seems that for windows it's not fully prepared

[saguillo2000]

https://medium.com/@oriolsaguilo/exex-of-reth-install-on-windows-16a12f843245

[kaxxa123]

I ran into this problem and troubleshooted it.

The bug is caused by this line of code in ./crates/storage/nippy-jar/src/lib.rs:
OpenOptions::new().read(true).open(parent)?.sync_all()?;

This is trying to open a directory. However on Windows this only works for files.
The directory path it tries to open, in my case was:
D:\reth_data\dev\static_files

Fixed this by filtering out the code in case of Windows:
#[cfg(not(windows))]

This is what the complete fixed code looks like:

// fsync() dir if platform is not windows
#[cfg(not(windows))]
if let Some(parent) = tmp_path.parent() {
      OpenOptions::new().read(true).open(parent)?.sync_all()?;            
}

And of course the use clause...

#[cfg(not(windows))]
use std::fs::OpenOptions;

With this change the node is starting just fine.

Should I create a PR?
I am new to Reth.

[kaxxa123]

Actually here is the correct solution after checking how to do sync_all() on Windows...

Modify ./crates/storage/nippy-jar/src/lib.rs:

Add:

#[cfg(windows)]
use std::os::windows::prelude::OpenOptionsExt;

Replace:

OpenOptions::new().read(true).open(parent)?.sync_all()?;

...with

            #[cfg(windows)]
            OpenOptions::new()
            .read(true)
            .write(true)
            .custom_flags(0x02000000)   // FILE_FLAG_BACKUP_SEMANTICS
            .open(parent)?
            .sync_all()?;

            #[cfg(not(windows))]
            OpenOptions::new()
            .read(true)
            .open(parent)?
            .sync_all()?;

[mattsse]

that makes sense
do you want to submit a pr for this @kaxxa123 ?

[kaxxa123]

yes assign to me.