Transferring vault to a different machine about vault HOT 3 CLOSED

@hrishikeshrt copying the directory is the correct way to migrate
Are you sure the correct dependencies are installed? https://github.com/gabfl/vault#installation-and-setup
This could explain your issue

from vault.

Installation is correct (or at least I feel so, because I can have a local vault on both the systems, but if I transfer one .vault folder to the other machine, it no longer accepts master key.)

To elaborate,
machine A: pyvault 2.4, local vault exists and works (sqlalchemy 1.3.22, sqlcipher3 0.4.5)
machine B: pyvault 2.4, local vault exists and works (sqlalchemy 1.3.22, sqlcipher3 0.4.5)

Transfer .vault from A to B, the entry screen that asks for master key, says that master key is incorrect.
Same, the other way around.

Both systems are Ubuntu 18.04. One has python 3.8.8, the other has 3.8.5, but I didn't think that would be an issue.

Edit: I updated the python version, and did not make a difference.

from vault.

Okay, it seems like the version of apt package libsqlcipher-dev was different on both systems, one was 3.4.1 while the other was 4.3.0.
I upgraded the 3.4.1 system to 4.3.0 and now it opens the vault. (Needless to say, now it breaks the local vault, but that is okay for my use case since I wanted to transfer the vault anyway)

Still, I feel like this was somewhat unexpected behaviour, potentially breaking vault across versions without any clear indication of why (since no error is thrown, just key isn't accepted). I am wondering if it's a good idea to note the system's libsqlcipher-dev version (and any other versions which might affect) in the config file, so that replication is possible.
(Another one of the sad scenarios could be an apt upgrade breaking the vault)

On further reading, it seems like newer versions can open older databases. More about the incompatibility and workarounds mentioned here: https://www.zetetic.net/blog/2018/11/30/sqlcipher-400-release/ in the Compatibility section.

from vault.