Does not support UNC path for database #10018

Describe the issue

Bitcoin Core 0.14.0 does not support storing the database on a SMB share.

Can you reliably reproduce the issue?

Relocate your AppData folder by right clicking on it, selecting the Location tab, and specifying a UNC path for a SMB share. Install Bitcoin Core 0.14.0 and run it. Technically it was relocated via a Group Policy Object, but the instructions here are functionally equivalent. Edit: It will function properly if you map the share with a driver letter rather than a UNC path.

Expected behaviour

It should support storing the database on a UNC path for virtual desktop infrastructure environments.

Actual behaviour

It complains about not being able to open the database.

Screenshots.

http://imgur.com/a/qTJkp

What version of bitcoin-core are you using?

Version 0.14.0 downloaded from bitcoin.org on 3-16-17

Machine specs:

• OS: Windows Server 2016 virtual machine with the latest patches and the Remote Desktop Services role, publishing Bitcoin Core as a RemoteApp. The host is running VMware ESXi 6.5
• CPU: 4 cores from a Intel Xeon E5-2660 v2 with high latency sensitivity and 100% reservation
• RAM: 16GB with 100% reservation
• Disk size: Boot disk is 32GB, the AppData folder is on a 20TB SMB3 share with 4+TB free
• Disk Type (HD/SDD): Boot disk is stored on a VMware datastore composed of 8x SSDs in a RAID 0 with a VMware NVMe disk controller for the virtual machine.

Any extra information that might be useful in the debugging process.

db.log was empty, the contents of debug.log is: 2017-03-16 22:15:24 Bitcoin version v0.14.0 2017-03-16 22:15:24 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1 2017-03-16 22:15:24 Assuming ancestors of block 00000000000000000013176bf8d7dfeab4e1db31dc93bc311b436e82ab226b90 have valid signatures. 2017-03-16 22:15:24 GUI: "registerShutdownBlockReason: Successfully registered: Bitcoin Core didn't yet exit safely..." 2017-03-16 22:15:26 Default data directory \SERVER_NAME_CENSORED\NAS\Application Data\Bitcoin 2017-03-16 22:15:26 Using data directory \SERVER_NAME_CENSORED\NAS\Application Data\Bitcoin 2017-03-16 22:15:27 Using config file \SERVER_NAME_CENSORED\NAS\Application Data\Bitcoin\bitcoin.conf 2017-03-16 22:15:27 Using at most 125 automatic connections (2048 file descriptors available) 2017-03-16 22:15:28 Using 32 MiB out of 32 requested for signature cache, able to store 1048576 elements 2017-03-16 22:15:28 Using 4 threads for script verification 2017-03-16 22:15:28 Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010) 2017-03-16 22:15:28 scheduler thread start 2017-03-16 22:15:28 Using wallet wallet.dat 2017-03-16 22:15:29 init message: Verifying wallet... 2017-03-16 22:15:30 CDBEnv::Open: LogDir=\SERVER_NAME_CENSORED\NAS\Application Data\Bitcoin\database ErrorFile=\SERVER_NAME_CENSORED\NAS\Application Data\Bitcoin\db.log 2017-03-16 22:15:31 Bound to [::]:8333 2017-03-16 22:15:31 Bound to 0.0.0.0:8333 2017-03-16 22:15:32 Cache configuration: 2017-03-16 22:15:32 * Using 2.0MiB for block index database 2017-03-16 22:15:32 * Using 8.0MiB for chain state database 2017-03-16 22:15:32 * Using 290.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space) 2017-03-16 22:15:32 init message: Loading block index... 2017-03-16 22:15:33 Opening LevelDB in \SERVER_NAME_CENSORED\NAS\Application Data\Bitcoin\blocks\index 2017-03-16 22:15:33 IO error: C:\Program Files\Bitcoin\SERVER_NAME_CENSORED\NAS\Application Data\Bitcoin\blocks\index\LOCK: Could not lock file. 2017-03-16 22:15:45 init message: Loading block index... 2017-03-16 22:15:45 Wiping LevelDB in \SERVER_NAME_CENSORED\NAS\Application Data\Bitcoin\blocks\index 2017-03-16 22:15:45 Opening LevelDB in \SERVER_NAME_CENSORED\NAS\Application Data\Bitcoin\blocks\index 2017-03-16 22:15:46 IO error: C:\Program Files\Bitcoin\SERVER_NAME_CENSORED\NAS\Application Data\Bitcoin\blocks\index\LOCK: Could not lock file. 2017-03-16 22:15:47 scheduler thread interrupt 2017-03-16 22:15:47 Shutdown: In progress... 2017-03-16 22:15:48 Shutdown: done

LevelDB (Core's db engine) is known to have issues with network shares, particularly Samba shares. That Core crashes when the datadir is on a network share is a known issue that currently has no fix that does not involve special configuring and symlinking.

@achow101 could you provide instructions this special configuration and necessary symlinks? I'd rather store it on a SMB share than have to setup iSCSI mounts if possible.

I haven't done this myself, so I can't really provide detailed instructions. Also, doing this doesn't actually move everything to the network share, only the block files. The databases must be local otherwise they will fail to work.

Basically you can symlink the blocks folder and everything that is not a database to your network share, but leave the databases (chainstate and database folder) on the local drive.

@achow101 Could you tell me which files (LevelDB or otherwise) are specifically required to be on an actual file system as opposed to an SMB share? Thanks.

Everything in $DATADIR/blocks/index and in $DATADIR/chainstate needs to be on an actual filesystem.

Thanks @sipa

@NicolasDorier in #10000 has the opposite observation, that a datadir on a SMB mount works in Windows (just not from Linux). Not sure what he's doing different.

It has been a while since I did not started bitcoind on a shared drive. But I think it should always work. @marukka try to assign a drive letter to your share. I noticed path starting with // does not work, but if it is a drive letter, it should be fine.

So it looks like it does work on Windows with a SMB share as noted by @NicolasDorier in #10000. It however requires the SMB share be mapped as a driver letter than a UNC path. So i'm reopening this because it should support a UNC path as well, instead of requiring a drive letter.

It looks like the double \\ at the beginning gets lost. Sometimes the shell eats these. Can you try reversing the slashes, e.g. // instead?

So i'm reopening this because it should support a UNC path as well, instead of requiring a drive letter.

Why? UNC support isn't claimed, so how can the lack of it be a bug? Where does it say UNC paths "should" be supported? This can only be a new feature request as long as @achow101's first comment stands.

@laanwj Forward slashes don't work. The … button won't recognize them and typing it manually in to the field says gives an error of Cannot create data directory here - https://my.mixtape.moe/oguyso.png @unsystemizer Where does it say that you support drive letter paths? Where does it say you support anything at all? If you want to go down this path, you support Windows and UNC paths have been around in Windows since at least the early 90s - https://www.google.com/patents/US5341499?pg=PA6&dq=%22universal+naming+convention%22 This isnt some sort of new feature or API, and certainly isnt obscure as it is the standard way of specifying network file systems which is rather common nowadays - just look at roaming profiles as an example.

Furthermore the fact that it allows me to set one in the first place and correctly reads the amount of free space available implies the UNC support is intended - https://my.mixtape.moe/lhvuzz.png. If UNC is not supported as you claim then it shouldnt even allow me to specify a UNC path, and would be a bug in that regard, as then Bitcoin Core is failing to validate input when it has a specific feature to validate input if you see my reply in this post to @laanwj.

And finally in regards to your qualifier of "as long as @achow101's first comment stands", if you were to read my previous comment in this thread and read #10000 the issue of LevelDB with SMB shares seems to be confined to Linux systems. It has so far worked fine as long as you specify a drive letter. And if you look at at the debug.log it seems to be simply using a relative path rather than absolute path for a lock file when a UNC path is specified - 2017-03-16 22:15:33 IO error: C:\Program Files\Bitcoin\SERVER_NAME_CENSORED\NAS\Application Data\Bitcoin\blocks\index\LOCK: Could not lock file. Which seems like it would be an easy bugfix for someone familiar with Bitcoin Core's code base.

@marukka

I agree it's a bug that the selection window does seem to support UNC. The reason for this is that the actual database is managed by LevelDB which does not support it. I don't know what would be required to make it work, but it may be more complicated than just not making it treat it as a relative path.

More generically, I'm surprised that drive letters mapped to network drives work at all. Having the database on network filesystems is not generally supported due to lack of atomic updates.

@marukka I completely lost interest in this due to your rant. You don't get to determine anyone else's priorities. If you think it is so easy, and want this to be solved, solve it yourself. That's how open source works.

@marukka I am busy on other things, but basically mapped drive works fine. I can help reviewing and testing if you do it, but I can't really work on it for now.

Bitcoin core should work fine with //, there is lots of scenario where it makes sense. An example is having an highly available bitcoin core, where a new server can be popped up and booted as soon as the current server burn. (see example http://haishibai.blogspot.jp/2017/03/setting-up-highly-available-minecraft.html)

Workaround of mapped drive work, but I remember case in the past where in some environment I did not have this flexibility.

@laanwj I didnt mention anyone's priorities... ever. I mentioned that @unsystemizer couldn't be bothered to read a thread before commenting. And was inventing in his mind a list of supported features so detailed it could be a RFC, which seemingly doesn't exist. And no, thats not how open source works, thats how amateurs work. There are countless professional open source projects which accept bug reports without trying to use some contorted logic to justify reports not being a bug, or crying to the reporter to fix it themselves. Some people actually take pride in developing functioning software, but it seems as if they're in short supply in this project.

Bitcoin Core accepts UNC paths as a data directory, this is a simple fact. And it crashes when attempting to use the UNC path, another fact. Regardless of whether you want to call the lack of proper input validation the bug, or it crashing the bug, it is still a bug, which is another fact. Instead it seems that the egos of some people here are so fragile that they apparently have problems accepting the fact that their code may contain bugs. If you require a safe space away from users reporting bugs, make this repo private. @NicolasDorier I can confirm that a mapped drive works as well, thanks for that info from #10000. Unfortunately I can also confirm that // does not work on Windows. There is a screenshot in my previous post.

As far as a highly available Bitcoin Core node it is likely already possible, at least on Windows. Just setup bitcoind as a service, and with Windows Server Failover Clustering (WSFC) it is fairly easy to configure a failover service. As far as shared storage though it would require a iSCSI mount (or something else like FibreChannel), but WSFC does not support SMB as shared storage except for the witness node to obtain quorum.

@marukka The issue is open, someone could pick it up. No one is denying that the issue exists, or it would have been closed. You're accomplishing nothing with your rant and wasting time. That's my last word on this.

@laanwj You intentionally misclassified it as a feature request rather than a bug, which is in effect denying that it is an issue. Call it what you want, but my comments are not rants, it is nothing more than refuting baseless and factually incorrect statements.

I'm just getting into Bitcoin, and I wanted to secure my wallet installation. My first thought was to create a persistent Freenas volume across 3 drives, and create a SMB share accessible by Windows, and run my wallet from there. I'm running into this same problem now as well.

However, what @marukka said isn't working for me: "It however requires the SMB share be mapped as a driver letter than a UNC path." My share is mounted to Q:, but -datadir=Q:\conf gives Error: Specified data directory "" does not exist.

There are certainly other ways to secure my wallet, but I thought I'd chime in on why this is a problem for me.

@ajthemacboy try with / instead of \

@NicolasDorier Thank you, that works!

Is this still an issue with a recent version of Bitcoin Core? If yes, what are the steps to reproduce?