KeePassXC cannot save files correctly to GVFS mount point

[blasco51]

Overview

Ubuntu 20.04 KeePassXC umounts Google Drive folder while trying to save converted database file on it. Then opens read-only the database file stored on Google Drive folder.

I'm trying to move to keepassxc from keepass 1 My database is stored on Google Drive. I access it using the Ubuntu standard tool which utilizes Nautilus file manager. Thus Google Drive is seen as a mounted network disk.

Steps to Reproduce

1. Database file produced by Keepasdroid on Google Drive
2. Google Drive mounted by Ubuntu 20.04 Nautilus file manager as a network disk
3. KeePassXC opens database file as a version 1 file to import
4. When saving database on the same Google Drive folder the network disk is unmounted
5. The database file remains with temporary extension and is unusable
6. Re-mount Google Drive
7. Open database file, convert and save it on a local folder
8. Move the .kdbx file to the Google Drive folder
9. Open it, do some mods and close
10. Re-open it, the mods are lost.

Expected Behavior

Having the database file stored on a local folder or on a mounted network disk should not be different for KeePassXC

Actual Behavior

The Google Drive network disk is not properly managed

Context

KeePassXC - Version 2.4.3 Revision: 5d6ef0c

Operating System: Linux Ubuntu 20.04 Desktop Env: Gnome Windowing System: X11

[phoerious]

We are not mounting or unmounting anything.

[blasco51]

Well maybe Nautilus unmounts Google Drive as a result of improper action by keepassxc

[blasco51]

I realized version 2.4.3 from the ubuntu repository is not the latest. I installed version 2.5.4 from ppa:phoerious The behaviour remains exactly the same :-(

[droidmonkey]

The opening of a file as read only is fixed in 2.6.0. Try our beta build.

[blasco51]

Well now the database file is saved on google drive but the original file name is lost. It is stored with something that looks like a temporary name: 1BdtRu8yCTCMjJW1O4knX74O0L0mUMeek

[droidmonkey]

Ummm that's unique!

[blasco51]

I tried that: 1- open the "strange name" file 2- save database as "new file name" on a local folder 3- open "new file name" 4- save database as same "new file name" on google drive Saving fails and google drive is unmounted :-(

[droidmonkey]

Do you have safe file saves enabled? We don't do much outside of standard Qt file calls. Does any other app have trouble with the Google drive mount?

[blasco51]

With "safe file saves" enabled I get the unmount problem when saving a new file. Without it I get files saved with the strange temporary name. I don't have troubles with other apps. I.e. I noticed that when libreoffice edits a google drive file a temporary file name is shown on its window top (that does not happen with a local file). Nonetheless then the file is saved correctly with its name on google drive.

[droidmonkey]

So I just tried replicating this on Ubuntu 20.04, using standard Google account features in Gnome. When I tried saving a database to the GVFS mount, GVFS crashed. This is probably why you are seeing it unmount/mount again. It crashed with a null pointer error. This is clearly a bug in GVFS when using QSaveFile type operations. QSaveFile works by writing to a temporary file next to the real file, deleting the real file, then renaming the temporary file as the real file name.

[droidmonkey]

Here are the results of my testing:

Safe Saves ENABLED:

• Temporary file is created and written to in the GVFS folder (Passwords.kdbx.XXXXX)
• GVFS crashes
• Temporary file remains indicating that QSaveFile::commit() could not complete
• Edits to existing files fail to save

Safe Saves DISABLED:

• Writing a new database to the GVFS folder worked flawlessly
• Saving an existing database file fails with "Cannot find file or folder"
• Re-opening the file and editing it works but the really long file name occurs

[blasco51]

Thank you very much droidmonkey! You pointed very well the problem. But I wouldn't be so sure about a bug in GVFS. Just because other apps that open and save files to GVFS mount point don't have the same problem. You can try and see.

[droidmonkey]

Under no circumstances should it be possible to crash GVFS. That is a bug.

[blasco51]

Well, I see your point, I will try to open a bug under gitlab.gnome.org But the "saving an existing database" problems still stands

[droidmonkey]

The problem is that Qt receives the file name as something like /run/user/1000/gvfs/google-drive:host=.../1BdtRu8yCTCMjJW1O4knX74O0L0mUMeek instead of google-drive://passwords.kdbx. So when the database is saved that is the file path that is used. Which is why that crazy long name is used, btw.

[blasco51]

That crazy long name is just the temporary file name. KeePassXC should not use that name but save the file with its original file name. I guess for example Libreoffice does it that way since it shows the crazy long name while editing but uses the original name when saving. You can test and see

[droidmonkey]

I have no idea how to get the original file name, it does not appear when choosing the file at all. Regardless, that shouldn't be our responsibility, we are technically saving to the temporary file and GVFS needs to do the translation for us. Perhaps because of the manner in which we save files it is getting confused. We do not save directly to the existing file, we write a temporary file, delete the original, and move a new file to where the original file was.

[blasco51]

Can't you try to avoid deleting the original file? And close by saving the temporary file onto the original?

[blasco51]

It looks like I have to give up using KeePassXC because of its incompatibility with Google Drive on Linux :-(

[Hedroom]

(Edited for formatting) Hello,

I am having exactly the same issue as blasco51, using what appears to be the same setup (details below) of Ubuntu 20.04 and KPXC 2.6.0.

Using 2.4.3 under Ubuntu 19.04, this was never a problem, and safe saving worked, preserving the filename. Is the above thread an indication that this is purely a GVFS issue in Ubuntu 20.04?

Steps to reproduce:

1. Open a password database on Google Drive
2. Make any changes and save the database
3. Fails to save
4. Disable safe saves
5. Save successfully, but with new random filename

Expected Behavior

Saving a database should preserve the original filename.

Actual Behavior

The filename is changed after every save.

Context

Fresh installation of Ubuntu 20.04 KeePassXC 2.6.0 installed from https://launchpad.net/~phoerious/+archive/ubuntu/keepassxc (repo was added to my sources to keep updating) Syncing to Google Drive via native Ubuntu Online Accounts service, GVFS via Nautilus file manager

[NOTE]:

KeePassXC - Version 2.6.0 Revision: 0765954

Qt 5.12.8 Debugging mode is disabled.

Operating system: Ubuntu 20.04 LTS CPU architecture: x86_64 Kernel: linux 5.4.0-40-generic

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (signed and unsigned sharing)
• YubiKey
• Secret Service Integration

Cryptographic libraries: libgcrypt 1.8.5

[NOTE]:

Operating System: Linux/Ubuntu 20.04 Desktop Env: Gnome Windowing System: Xorg

[droidmonkey]

I'm surprised this worked for you at all in 2.4.3 because it should have opened the database read only.

[mdeguzis]

This also is a huge problem for me and how I accidentally lost my main passwords file (now I use a crontab and "drive" for linux to pull them hourly). This is the only app I this issue with. Gnome + System 76 Pop!_OS.

For now, I am using grive instead (there are others of course at https://www.ubuntupit.com/top-12-best-google-drive-linux-client-software/) to sync files. Hope this gets fixed so I can use the built-in gvfs support in Gnome 3.

[Hedroom]

I'm surprised this worked for you at all in 2.4.3 because it should have opened the database read only.

I'm very sorry, my mistake - I think it might have been 2.4.1 that saved correctly. I neglected to make a note of the version I was using more successfully before I upgraded my OS and then installed 2.6.0.

[sashadereh]

Just adding +1, I also encounter this problem.

[anuneo]

Hey, I have this problem as well. Any idea, when it will be fixed? Thank you for your help :)

[droidmonkey]

This will be fixed in 2.7.0.

[Hedroom]

Thank you, and Merry Christmas!

[romainjacquet]

I report that I had a very similar problem with Keepass 2.4.3. When opening keepass database stored on a Google Drive network share, the database is open read-only. In the title of the tab, I got "MyDATABASE [Read-only]". I try the original application Keepass and the problem is really worse. When saving the file, nothing is saved and the file is truncated to zero.

Keepass is using Mono runtine for IO operations and KeepassXC uses the native functions provided by QtCore. Because both Keepass and Keepassxc are concerned, I think so the problem could come from the underlying VFS. I mean the code of gvfsd-google daemon, which is part of gvfs-backends 1.44. I'm going to perform more tests.

[janlucaklees]

Having the same issue with Gnome on Manjaro Linux. I think it's the same as described here. All I can add is that it seems KeePassXC, or something in between KeePassXC and Google Drive, tries to save the file not under the original name, but under the file id that Google Drive uses internally.

Thus a new file is created which of course gets a new id. So that opening and saving it again, will result in yet another file created.

I mean, knowing that, one could just name their password db just as the Google Drive file id.

[droidmonkey]

The crazy thing about this bug is that the file chooser gives us the path to the file ID version. That is a backend implementation detail of gvfs that we shouldn't have to deal with. I've tried several methods to get the front-end path to the file using Qt and failed to get it to work. Hence why this is still open.

[janlucaklees]

But they can show the files names correctly in their file explorer. There's gotta be a way. :thinking:

[droidmonkey]

In file explorer you are seeing the "front end" of GVFS which is user focused. The file chooser dialog, however, returns the "back end" file path for GVFS which should really not be exposed to programs. Everything should go through the front door, but it doesn't, so any program that does not write directly to the provided file node in the back door will have this error. The way saving works in KeePassXC is we write a temporary file right next to the real one, delete the real one, and rename the temporary file. This prevents data loss due to interrupted file writes. This also prevents us from using the GVFS backdoor and why your files get named the file ID instead.

[janlucaklees]

Yeah, this is what I just found out over at the GNOME GitLab project.

So basically, besides customizing KeePassXC to work with GVfs there's nothing we can do about it.

[droidmonkey]

Bingo

[spoonerandrew]

Just to add that the same behaviour is happening on Fedora 34 with KeePassXC 2.6.4

[robellegate]

As @droidmonkey has already stated, the weird file name is the back-end file name used by Google Drive. The way Gnome applications such as Nautilus gets the file name is from the standard::display-name metadata. You can see this information using gio:

gio list -a "standard::display-name" 'google-drive://<your_email>@gmail.com/My Drive'

Perhaps the display name could be used in place of the file path in the UI? I'm currently digging through the gvfs source code to see if this metadata can be exposed another way.

[droidmonkey]

For information, I added a fix for this in the develop branch. You can choose to "direct write" the database file which is the only way to save files correctly using GVFS.

[lawrence-laz]

For information, I added a fix for this in the develop branch. You can choose to "direct write" the database file which is the only way to save files correctly using GVFS.

How dangerous is this? If connection drops during save, is .kdbx file screwed?

[droidmonkey]

Yes, very dangerous from that perspective. But Google would have a backup of your database server side if that happened.

[lawrence-laz]

Oh, as long as the file can be recovered it's fine then I guess

[michaelk83]

Oh, as long as the file can be recovered it's fine then I guess

You should always keep your own backups as well, regardless of which save method you use.

[droidmonkey]

Fixed with #6594

[Excrubulent]

I just had this same issue on KeepassXC 2.7.1 on Ubuntu 22.04 using the built-in Gnome integration of Google Drive.

Let me know if you want any more details.

EDIT: I should also mention the UI for KeepassXC hangs when attempting to open the file on google drive from within the app, using the Open Database option. It opens properly when opening it from the file manager using the Open With feature. Not sure if this is a clue to what's going on but it might be relevant.

[campey]

I just had this issue on KeepassXC 2.6.6 [default] on Ubuntu 22.10, using Gnome google drive like @Excrubulent above.

It ended up renaming, and deleting the file. (In a way that permanently deleted the file on Google drive, and Google wwon't take service requests to restore such permanently deleted app backup files it seems) It was rather stressful as I hadn't been diligent with backups for a while. Luckily my phone still had a local cache and I was able to export a backup from there.

I have installed 2.7.4 and will retry and share experiences.

Please ask if you'd like any specific info, or if there is a work-around.

[campey]

[EDIT] In trying to upgrade to 2.7.4 installed 2 different keepassxc's side-by-side. 2.6.6 installed from source: "ubuntu-kinetic-universe" installed as "KeePassXC" 2.7.4 installed form source: "snap store" installed as "keepassxc"

2.7.4 would not even open my file (hung after selecting the file) so, unfortunately, can't test this. 2.6.6 saving with "safely save" unchecked results in the file disappearing, the drive folder activity shows only that the file was "permanently deleted", with safe saves, get the temp file and rename issues exactly as reported by @droidmonkey, so as would be expected I suppose.

"work-around": I will continue using KeepassXC 2.6.6 on ubuntu to access passwords, but not save any new passwords in via there.

[droidmonkey]

Use our flatpak deployment or appimage, not snap. Snaps are garbage. The 'better' alternative saving strategy was introduced in 2.7.0, so 2.6.6 is considered buggy at best.

[campey]

fwiw I just tried with appimage. It uses a different file browser that didn't have a way to browse to the google drive (no links to the "gnome" google drive), and the open database dialogue keeps going unresponsive.

When I pasted in the google drive link from "Files" browser on ubuntu, /run/user/1000/gvfs/google-drive:host=[domain],user=campey/[long_id] then I see the files with their google files ids in the browser there, and it hangs again.

[droidmonkey]

Welcome to the state of the linux desktop... ugh

[campey]

For completeness, I tried with flatpak, selecting the database file caused it to hang (left for a minute or so) without asking for password or key file. Then based on another comment I read, I tried to open it using the "open with..." context menu, which got me to the password screen, and I could successfully choose key file and enter password. But then, it didn't open the file, failing with the message: "Error while reading the database: No root group"

So, I'm going back to 2.6.6 for at least being able to read, please feel free to let me know if you'd like any more tests/info.

[droidmonkey]

That error message indicates a corrupt database file or truncated reading