Sync of KeeShare files with two parallel used KeePassXC (on 2 PCs) leads to endless loop until crash. Simple solution!

[Hannah-Bee]

Overview

I use KeePassXC on two PCs with different databases. The databases are stored on the shared NAS. To be able to share entries between the two databases, I recently enabled KeeShare (incl. import/export) and stored personal certificates. I have set up KeeShare for several folders and placed the *.kdbx.share files on the shared NAS. The exchange of entries is in principle problem-free in both directions (import / export from PC1 to PC2 and vice versa). However, there is a problem if KeePassXC with activated KeeShare is running on both PCs at the same time. Then both instances get into a loop of retrieving the changes and saving until one of the programs crashes.

Steps to Reproduce

In detail it seems to happen like this:

1. KeePassXC on PC1 is started.

2. A synchronization of the KeeShare files *.kdbx.share takes place.

3. For some reason, each single .kdbx.share is then saved again. Recognizable by the timestamp. As long as only one instance accesses the .kdbx.share at the same time this is surely no problem.

4. If now KeePassXC is started on PC2, the same happens: the *.kdbx.share files are retrieved and for some reason saved again (see timestamp).

5. The instance on PC1 now recognizes from the change of the timestamp field .kdbx.share on the server that the file has been changed. The .kdbx.share is retrieved and now stored again with a new timestamp.

6. This leads to the fact that on PC2 by the change of the timestamp a call of the data takes place, which are stored again with new timestamp.

7. Both instances are in an endless loop, which can only be terminated manually or by the crash of the program. Error message on crash:

8. If one instance has crashed, it is possible to work normally again on the remaining instance.

Expected Behavior

NOTE: # For synchronization the *.kdbx.share file should probably be retrieved read-only. The file should not be stored again with new timestamp.

Actual Behavior

NOTE: # During synchronization the *.kdbx.share file is read and then stored with a new timestamp, which triggers a data synchronization for the linked instances.

Context

The problem could probably be solved relatively easily: If a *.kdbx.share is only saved (and consequently stored with a new timestamp) when there is a real change of entries. The retrieval of the data and the transfer to the parent database must not result in a save. Would be happy if someone could take a look at this problem. KeeShare works in principle really great, but is almost unusable because of the bug.

KeePassXC - VERSION 2.6.4 Revision: REVISION 34a78f0

Operating System: Windows 10 @ both PCs

[droidmonkey]

Keeshare is fairly broken, unfortunately. It's on my refactor list for 2.7.0. Edge cases like this are not handled well. It is also meant for two different databases to share a common database between them. Opening the same database with the same share will necessarily cause problems.

[Hannah-Bee]

I do not use the same database. Each KeePassXC instance on PC1 and PC2 uses its own database (PC1.kdbx and PC2.kdbx). I use KeeShare to share individual folders between PC1.kdbx and PC2.kdbx. KeeShare is actually a great feature. I would be happy if you continue to follow this and not lose sight of it :-)

[droidmonkey]

Well that's interesting! I've tested keeshare on two databases without a network share in between and it works fine.

[Hannah-Bee]

When I do this there is a real firework of save, retrieve, sync.... In the File Explorer you can see how the timestamps are adjusted every second without me making any change.

My setting: PC1 @ Windows with PC1.kdbx on SynologyNAS PC2 @ Windows with PC2.kdbx on SynologyNAS KeeShare file "SharedFolder.kdbx.share " on SynologyNAS Personal KeePass certificates created (PC1_certificate / PC2_certificate) and set to "always trust" on both computers All on the same network.

PC1.kdbx <---> SharedFolder.kdbx.share <---> PC2.kdbx

[droidmonkey]

I'll see if I can hotfix not saving the share file when there are no actual changes.

[Hannah-Bee]

That would be very cool.... maybe that solves the problem already. Because apart from that, the synchronization actually works quite well.

[mustekito]

I have exactly the same problem but I do the synchronisation with Dropbox.

My setting: MyPC @ Linux with PC1.kdbx on Dropbox MyPartner @ Windows with PC2.kdbx on Dropbox ARelative @ Linux with PC3.kdbx on Dropbox KeeShare file "MyPartner.kdbx.share " on Dropbox KeeShare file "ARelative.kdbx " on Dropbox

PC1.kdbx <---> MyPartner.kdbx.share <---> PC2.kdbx PC1.kdbx <---> ARelative.kdbx <---> PC3.kdbx

I have experienced the sync loop three times in the last 3 months, 2 with ARelative and 1 with MyPartner, and my solution was to delete the KeeShare databases and start from zero.

Thank you for making KeePassXC!

[droidmonkey]

I've been trying to replicate locally without success. Are there any special entries in your database like with references or ssh agent or similar?

[mustekito]

I have the ssh agent enabled. No references in my case. In fact, I just discovered this feature. I didn't know it before.

[Hannah-Bee]

ssh agent is disabled for me... no references in db

[Hannah-Bee]

there must be a reason why the share file is saved again directly after reading. If this can be prevented or if it can be achieved that the share file is only written when a change has been made to the data, then this should interrupt the loop.

[mustekito]

I am remembering now that on 2 out of 3 occasions the problem started after KeePassXC asked me if I wanted to merge the DB.

Yesterday in my laptop (Windows), I opened my BD before Dropbox did the sync (my fault, I didn't realise). When Dropbox synced, KeePassXC asked me if I wanted to merge the DB. I clicked no because I wanted KeepassXC to use the new file that Dropbox had downloaded. Finally, I modified an unshared entry.

Today, in my desktop (Linux), I opened my BD after Dropbox did the sync. No problem here, but in the shared Dropbox folder there were "conflict" copies of the shared kdbxs files. Not for the case of the main DB (PC1.kdbx).

I don't know if that suggests any ideas that originate the loop. It seems that the main DB incorporates a different version of the shared DBs or something like that

[Hannah-Bee]

I dont have to merge.... It is enough to open two different databases on different computers to trigger the loop. The shared folder can already be integrated into both databases.

Do you think it has something to do with the fact that I have more than one shared folder? But actually this should also work with multiple folders.

[mustekito]

I don't think so but I am just a user like you 😅. In my case, I was working with two shared folders without any problem for weeks but when the loops start, I spend 1 hour deleting the shared database, creating a new one... or changing the keeshare mode to "import" on one of the PCs. The last one is only a temporary solution because it prevents using the "synchronise" mode again. The bug is a pain in the ass.

Maybe the solution is related to what you mentioned before: why does KeePassXC save again all DBs after reloading a shared DB without any change (only the timestamp)? I guess it is because the main DB has a copy of the shared DBs but I don't know.

In fact, if I make a change in MyPartner.kdbx.share, the other shared DB (ARelative.kdbx) is also exported.

[droidmonkey]

This could be directly related to using signed shares. Try using just a plain kdbx file for your keeeshare share file.

[Hannah-Bee]

What do you mean? Create an empty database and see if the share works without loop?

[mustekito]

This could be directly related to using signed shares. Try using just a plain kdbx file for your keeeshare share file.

I thought about it. That was the reason why I moved my ARelative.kdbx.share to ARelative.kdbx but without result. The problem reappeared in the new unsigned shared database a few weeks later.

[droidmonkey]

Ok gotcha. I'm in the middle of refactoring keeshare, I'll post a test build when ready.

[mustekito]

OK. Thanks!

@Hannah-Bee do you open and edit your database in other app different from KeePassXC such as Keepass2Android on Android?

[Hannah-Bee]

Yes, in KeePass2Android... But not while i was trying to set up KeeShare

[mustekito]

Yes, in KeePass2Android... But not while i was trying to set up KeeShare

I am trying to look for common things in case that helps to figure out what is going on.

I also use Keepass2Android. A few days ago I edited a shared entry from Keepass2Android. But since then I opened the database in KeePassXC and in theory the shared database should be updated at that time. Today the other person opened his database and that is when the loop started. I don't know if this is related because we have done this before without this annoying result.

[Hannah-Bee]

While I set up KeeShare, there was no sync from KeePass2Android. I set up KeeShare on two computers at the same time. At the moment the connection between PC1, PC2 and the share file was set up, the loop started.

[4SiB]

The same with KPXC 2.6.6 and a share at Windows Server 2012R2 who works for FileShare service for ~100 users. My remote PC1 via VPN with own database, share one group to this \10.0.50.21..\sharedfolder.xdbx.share in sync mode. Local PC2, next to this FileServer server use KPXC 2.6.6 and sync the same file as KeeShare.

Local PC2 still show problem with read the share file , in loop.

My remote PC1 refreshing every few seconds.

This was done by 20minutes and app works stable, not any crash in my scenario. For me the KeeShare cannot be used.

I check use the same DB.kdbx at this server and both PC can use and work at the same file. We must wait longer to see changes from second computer but this way works better then KeeShare itself.

[tomaszguzialek]

Just to keep this thread alive, I encounter this problem every single time when I add an entry to the database in Keepass2Android and have KeepassXC open at the same time on my Mac. The desktop instance asks to merge changes and goes into a loop of merging. The database file is shared via Dropbox and has a KeeShare folder attached (also in Dropbox just next to the database file).

[4SiB]

Currently when I see the "Merge" button then I close Database file , next I open recent database and see new data :). So easy to workaround.

But I not know what to do to help solve this problem.

[mustekito]

But your steps are different @tomaszguzialek @4SiB. We, @Hannah-Bee and I, do merge anything. The loop starts without doing nothing.

[mustekito]

Ok gotcha. I'm in the middle of refactoring keeshare, I'll post a test build when ready.

Any news on this?

Thank you for your work and support!

[droidmonkey]

My second phase of refactor was shelved for the moment. It was too big and I needed to work on other things (powershell release tool and windows hello).

[tx3eh8IUD1]

I can replicate this issue as well. What works for me is to disable the option "Save automatically after every change". This will break the loop, and is a fine workaround. What triggered the issue was for me that I have duplicates of my database that I use on other devices. I typically don't edit them, but sometimes I have to. In order to get these changes to my master database, I open both and copy entries from A to B. Both, of course, are linked to the same KeeShare...

Edited to add: In my case, the loop does not crash the app, but you can see how each database is saved, one second after the other.

[tsilvs]

@droidmonkey

Ok gotcha. I'm in the middle of refactoring keeshare, I'll post a test build when ready.

Do you have any news?

[Franz-Heinz]

I know this bug report is rather old but I can confirm the problem on Ubuntu 22.04 LTS with KeePassXC 2.7.7

Thanks for the great work.