Keepassxc: KeepassXC not creating a .database.kdbx.lock file

[abacao]

Hello,

I'm sharing a vault and KeepassXC is not creating the .lock file, so I'm loosing some credentials that my team is storing.
KeepassX still creates the .lock file.

What happened? If I'm not mistaken, KeepassXC used to use it also.

[phoerious]

We removed the lock file a long time ago, since it creates more problems than it solves. If your remote file system supports it, KeePassXC reloads changes automatically so conflicts should happen rarely. 2.4 will also ship a patch to make that work over NFS.

[abacao]

I have tested with a dropbox sync and it doesn't work. Can this be a feature flag (on or off)?

[droidmonkey]

The lock file does not solve syncing or auto reload. It is especially not helpful using cloud sync services. KeePassX and KeePassXC are not necessarily designed for multiple parties using the database at the same time. We accommodate using autoreload and merge, but that is more the exception than the rule. Group sync (there is an open PR for this) will solve multiple parties using the same database together.

[abacao]

Thank you for the responses. Can you please point me to the PR to try to help?
The project is great and I know that KeepassXC is not meant to be used in teams and I'm a big advocate of your project but if it can't be more friendly for team use it will become harder to recommend it instead of another PM.

Your action removing the lock file went under our radar!

Thank you for all you efforts.

[droidmonkey]

The PR for group sharing is here: https://github.com/keepassxreboot/keepassxc/pull/2109

It needs a little work, but it very well thought out. Basically you share the main database which contains live links to sub-databases that are represented as groups in the master database. These are synced and merged automatically, can be read-only as well.

[phoerious]

If you sync your Dropbox into a local folder, KeePassXC will autoreload the changes as soon as they arrive. It will not and cannot, however, guarantee atomic file locking. If two people write at exactly the same time, one file will be overwritten. But that should not happen very frequently.

[phoerious]

That being said, lockfiles are especially useless for multi-party remote sync, because without the possibility to match the lock file with a local process ID, the application will discard it as stale and simply replace it with its own lock file. The only solution here would be not to discard stale lock files, but then you would have problems with it permanently, especially when someone's connection to the remote share dropped without proper cleanup. It is also not uncommon to have various conflict resolution copies of your lock file from your remote sync client after a while. So either way, it's not going to make anything better.

[abacao]

I understand the issue. Currently, by syncing with Dropbox and local, 2 team members can open the database and be unaware that the db is being consumed somewhere else.
The .lock file (even though it won't fix all the issues) it mainly served as a warning and 90% of the times it was effective.
Personally I liked the .lock because it's the behavior previous Keepass had and personally I think the default behaviour should be consistent with previous keepass and the no use of lock file should be a option but yet again I understand the issue.

May I suggest a different approach? Be able to say I only want this db to be read only. If a secret was necessary to be stored, keepass would warn and re-ask for the db password.

To be honest, I didn't understand if the issue pointed will benefit the use of the same db fully shared within a team (2 or more users).

[phoerious]

As I said. Unless for some magical reason, the auto reload logic doesn't work for one of you, there shouldn't really be a problem unless you are both constantly trying to save new changes to the database.

[Tartuffo]

@phoerious Re: "there shouldn't really be a problem unless you are both constantly trying to save new changes to the database", what do you think is a safe window / how frequently does the program check to see if the database has been changed? E.g. changes always > a few minutes apart should always be safe?

[phoerious]

A local database is almost instantly registered as modified, a remote DB may take a while, but it's only a few seconds at worst.