Keepassxc: DBs in samba shares open as read only.

[31337-4554551n]

Expected Behavior

When mounting a samba share in ubuntu, using the connect to server option in the nautilus gui, then opening a keepassxc database with keepassxc from that share, it should open and be able to be modified and saved.

Current Behavior

When mounting a samba share, via nautilus, in ubuntu, using the "Connect to server" option in the gui, then using keepassxc to open a database on that server, it opens in read only mode.
There is no warning about locking, or asking if you'd like to open anyway, it just opens, with a yellow bar across the top saying it's open in read only mode.
Modifying other files in this share via other tools works fine (text docs via gedit, renaming things, whatever)

Possible Solution

Mounting thusly works as expected:
mount -t cifs -o username=something,password=something //1.2.3.4/foo /mnt

Steps to Reproduce (for bugs)

1.Mount a samba share with nautilus connect to server option
2.open a keepassxc file in the share
3.
4.

Context

I want to have a keepassxc db on a shared location in my network, and access it from a few different computers.

Debug Info

KeePassXC - Version 2.2.0
Revision: 9a7e6850d6b79c47c2d46d99fdaf433c2ff13716

Libraries:

• Qt 5.7.1
• libgcrypt 1.7.6-beta

Operating system: Ubuntu Core 16
CPU architecture: x86_64
Kernel: linux 4.8.0-58-generic

Enabled extensions:

• KeePassHTTP
• Auto-Type
• YubiKey

[hifi]

I tracked this down to DatabaseTabWidget::openDatabase not using fileInfo.canonicalFilePath() as the constructor argument to QFile when testing database writability.

This only happens with GVFS mounted shares as FUSE exports at (/var)/run/user/<uid>/gvfs. Probably affects any location mounted through the mechanism.

The only difference between the fileName and the canonical file path is that the canonical path points to /run/... and fileName to /var/run/.... However, both locations work identically as /var/run is a symlink to /run. This points to a possible bug in Qt itself but can be worked around by normalizing all file usage to QFileInfo::canonicalFilePath().

Creating, opening and saving a database works fine with the change.

[phoerious]

Do you want to prepare a PR or do you want me to do it?

[hifi]

On it, just a moment.

[hifi]

I got a false positive. QFile in RW mode returns "Operation not supported" error (with code QFileDevice::OpenError) when trying to open over GVfs.

[hifi]

Created upstream bug report regarding this issue as it seems QFile is at fault here:

https://bugreports.qt.io/browse/QTBUG-62096

[Keisial]

@hifi note that the use of fopen(..., "rw") in your testcase is not standard. It should be fopen(..., "r+")

[phoerious]

We don't use fopen() directly. We use QFile::open() which accepts an enum of possible modes of which the ReadWrite mode fails.

[hifi]

@Keisial Wow, I completely forgot fopen() used r+ for RW. It starts failing as well when I fixed it, it's not a Qt bug either. My failure to jump to wrong conclusions all the time is starting to get annoying.

This seems to be a known issue with GVfs and working around it might not be as stupid as I thought:
https://bugzilla.gnome.org/show_bug.cgi?id=777152

[phoerious]

I suppose that means QIODevice::ReadWrite is actually append?

NVM, it's not. But it seems that everything without truncate fails, including r+ and a.

[31337-4554551n]

I was just wondering if this was still being worked on? I've not seen any
updates, so was wondering if this was moved to another job relating to
what's causing this or something?

On Sun., 23 Jul. 2017, 4:52 pm Janek Bevendorff [e-mail]
wrote:

I suppose that means QIODevice::ReadWrite is actually append?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/keepassxreboot/keepassxc/issues/803#issuecomment-317233403,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZMugujxBSkLcVLRO5W3Fg7hrhiaq9XMks5sQu3CgaJpZM4OfWQ-
.

[hifi]

@31337-4554551n Well, the issue is not with KeePassXC but with gvfs which is used to access a Samba share opened in the fashion you do.

That GNOME bugzilla entry is the one that needs to be poked at to get it fixed properly, unfortunately.

A workaround is possible in KeePassXC if the RW check of a database is converted to plain "does it look like it's writable?" instead of the current "can we append to the file if we wanted to?" but it might cause false positives.

[31337-4554551n]

Thank you. Could you please link me to that bug, and I'll try poke it there?
Also, is there any work arounds you can suggest to get the functionality
even if it requires a few extra steps?

On Sun., 10 Sep. 2017, 3:24 am Toni Spets [e-mail] wrote:

@31337-4554551n https://github.com/31337-4554551n Well, the issue is
not with KeePassXC but with gvfs which is used to access a Samba share
opened in the fashion you do.

That GNOME bugzilla entry is the one that needs to be poked at to get it
fixed properly, unfortunately.

A workaround is possible in KeePassXC if the RW check of a database is
converted to plain "does it look like it's writable?" instead of the
current "can we append to the file if we wanted to?" but it might cause
false positives.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/keepassxreboot/keepassxc/issues/803#issuecomment-328291613,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZMugkW_ffkQoEFQgnbcQKHH3vQ1DtHKks5sgsnCgaJpZM4OfWQ-
.

[sh3bang]

Same issue with WebDav.

I've mountet a WebDav source with GNOME Nautilus (gvfs) and can't choose the mount point within "KeePassXC Database Browser".

Workaround: press CTRL+L and enter the mount path manually.
But its only for opening, saving this way is not possible :(

[sh3bang]

Hello, is there any news about saving to GVFS?
Even with the new KeePassCX 2.3.0 i cant save to my WebDav or SAMBA share. File "is" write protected.

[droidmonkey]

As mentioned this is an upstream bug that affects several apps.

[sh3bang]

Surprise: Saving works! But ONLY with "Save as..." Option and selecting the GVFS "mount" directory like /run/user/12345/gvfs/...
Notive: I've installed KDE Plasma, GNOME, Cinnamon Desktop and KeePassXC 2.3.0.
Some libs like QT, GTK and so on was changed during install of these software...

[droidmonkey]

Do you have auto save after every change enabled? That disables the save button.

[sh3bang]

yes, it was enabled and i disabled it now but the "save button" is still disabled. Also after restart keepassxc. Also the message of write protected keepass file still appears after unlock but "save as..." on GVFS location works :)

[droidmonkey]

Read-only is triggered because a test of opening the database as read/write fails. This may be a Qt bug.

See gui/DatabaseTabWidget.cpp line 146-155

[hifi]

It's an upstream gvfs bug but we can work around it by throwing the RO test away and making sure an error message is shown if actual saving fails.

[elin-y]

Is there any workarounds for this bug, until it is fixed upstream? Is there any upstream bug reported, so that we can bump this issue?

[hifi]

@elin-y You can mount the share from command line directly to avoid gvfs issues. This requires root, though.

Upstream bug is mentioned in this comment thread but I'll link it again: https://bugzilla.gnome.org/show_bug.cgi?id=777152

[projetosvillevox]

@elin-y I'm using Ubuntu 18.04 and what kinda solved my problem was:

• Open the DB normally (will open as read only)
• ** Click on "Database" -> "Save Database as"
• Then find the mounted folder using the file explorer and overwrite the existing database
• Boom, now it's on read/write mode.

** The text might be a little different because i'm using it in Portuguese.

[31337-4554551n]

Annoyingly you have to do it every time. But yea, it is a work around.
Thank you :-)

On Sat., 21 Jul. 2018, 00:06 Projetos villevox, [e-mail]
wrote:

@elin-y https://github.com/elin-y I'm using Ubuntu 18.04 and what kinda
solved my problem was:

• Open the DB normally (will open as read only)
• ** Click on "Database" -> "Save Database as"
• Then find the mounted folder using the file explorer and overwrite
  the existing database
• Boom, now it's on read/write mode.

** The text might be a little different because i'm using it in Portuguese.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keepassxreboot/keepassxc/issues/803#issuecomment-406611001,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZMuggO_HjklZvdxcSjm_8EzjYQSoapaks5uIePggaJpZM4OfWQ-
.

[elin-y]

@hifi Hello Toni, thanks for the workaround, I'll try that, although it is cumbersome, better than nothing. And, sorry I had missed the link to the upstream bug before I posted my comment

@projetosvillevox I'm also using 18.04 and I had already tried to overwrite the existing database selecting "Save database as ..." option. It resulted in a completely deleted database! I was just so thankful to myself that I had a backup of it. It is a shared database with very sensitive and important information. It would be catastrophic if I didn't have any backup copy of it.

It seems there are bigger and dangerous bugs related to smb mounts/gvfs.

[hifi]

@elin-y If you're on a static network and the share is always available just add it to your /etc/fstab and use automatic mounting. If not, some other automatic mounting option might work (autofs et al.).

[elin-y]

@hifi I'm not on a static network. The database is in the office and only available if I am on site or over VPN. I'll look into automatic mounting options for Ubuntu 18.04 and hope to find a solution that works both on site and over VPN. Thanks for the suggestion.

[edencorbin]

Having this same issue, from the posts, I"m not clear on if its resolved, I have static home network and would like to access keepass from a few computers, I have a samba share setup and can open it read only, most other files open read / write. I have chmod 777 the folder and file.

[jokogr]

I am not sure if this issue is related with gvfs. My NAS SMB share is mounted via systemd and I have the same issue, the database files from that share are opened read-only.

Let me know if you need more info to report.

[msharp1]

@hifi Hello Toni, thanks for the workaround, I'll try that, although it is cumbersome, better than nothing. And, sorry I had missed the link to the upstream bug before I posted my comment

@projetosvillevox I'm also using 18.04 and I had already tried to overwrite the existing database selecting "Save database as ..." option. It resulted in a completely deleted database! I was just so thankful to myself that I had a backup of it. It is a shared database with very sensitive and important information. It would be catastrophic if I didn't have any backup copy of it.

It seems there are bigger and dangerous bugs related to smb mounts/gvfs.

I can confirm this use case is very dangerous. I also tried the "save as" trick and it resulted in completely lost database ! Can someone summarize the root cause of this issue so we can trigger /work on a effective solution ?
Regards,

[AngryUbuntuNerd]

Would it be possible to make this RO check optional, or being able to force a save attempt?

[Enpheebled]

I encountered this problem when trying to open a remote database that was mounted via sftp in Thunar on Linux Mint XFCE.

I managed to work around the issue by writing a shell script that creates a temporary sshfs mount point and opening the database from there.

If you don't use a key-based login to your remote system then you'll need to enter your user password before keepassxc starts.

It's not ideal, but it gets the job done.

This is the working script that I use. The 'netdir' and 'kpdb' script variables will need to be changed to suit your network path and database file name.

#!/bin/sh

########################################################################
#                                                                      #
#   Workaround for problem:                                            #
#       keepassxc databases opened via network paths are 'read-only'   #
#       and can not be edited or saved.                                #
#                                                                      #
#   Mount remote keepassxc directory via sshfs at temporary local      #
#   directory, then open keepassxc database via local mountpoint.      #
#   Finally, unmount the remote directory and remove the temporary     #
#   local directory.                                                   #
#                                                                      #
#   Requires installation of packages 'keepassxc' and 'sshfs'.         #
#                                                                      #
########################################################################

netdir='phil@emachine:/mnt/ntfs-media/keepass'
kpdb='phil.kdbx'
localdir=$(mktemp -d)

if [ -d "$localdir" ] 
then
    if (sshfs "$netdir" "$localdir")
    then
        keepassxc "$localdir/$kpdb"
        fusermount -u "$localdir"
    fi
    rmdir "$localdir"
fi

[volkertb]

Alright, this issue is now a year and a half old and and it's a real annoyance. It's not just SMB shares that are affected. This issue occurs with any kind of remote network share that is mounted through the GNOME file manager, through SFTP, WebDAV, etc.

May I suggest the following workaround:

• Check if the file path of the kdbx file contains the substring "/gvfs/".
• If it does, either disable the "read only" check and assume the file to be writable, or allow a "force save" option, as @AngryUbuntuNerd suggested.

Heck, if you add a "force save" option, you could even forego the checking of the "/gvfs/" substring.

What is the worst that could happen? The write action would fail and the application would then show an error message to the user. But hey, at least it tried.

This may ultimately be an upstream issue, but it has existed for a long time and it is unclear when it will finally be addressed. In the meantime, please add this automatic workaround to the otherwise awesome KeePassXC application, so we don't have to mess around with scripts or manual mounts to work around this manually.

Thank you kindly for considering this.

[droidmonkey]

Do note that the underlying bug in gvfs/fuse has a known working patch as of 3 months ago. When it will be merged is anyone's guess. Work arounds and false tests are not valid solutions to the problem.

https://gitlab.gnome.org/GNOME/gvfs/issues/249

Besides the read-only issue, we have intention to detect file changes prior to save to overcome overwriting databases shared this way.

[zetheroo]

We had these issues as well as others with our DBs stored on the network shares using KeePass2, but disabling the option _Use file transactions for writing databases_ solved it. Might there be something like that for Keepassxc?

[droidmonkey]

That option is equivalent to unchecking the "safe save" option in general settings

[webafrancois]

Mounting a webdav share with a network drive on Windows works. The database is writable and works correctly.
Mounting a webdav share with a gvfs mount on Linux don't work. The database is only readable.
A odt file locate on the same gvfs mount on Linux is writeable.
The option "save safe" on KeepassXC 2.5.0 is disable.

[ShinIce]

Mounting a webdav share with a gvfs mount on Linux don't work. The database is only readable.

use davfs on fstab

[webafrancois]

Yes, I know this tip and use it on my PC, but my users in my company, who are not root or sudo on their PC, can't do that. When I promote KeepassXC, I can't explain that they must edit the fstab and add reference to a secret directory wich contain credentials. It's too complicated.

Access files on a network drive shouldn't require a root acces, while others applications can access with writeable access.

[droidmonkey]

As noted above this isn't a bug in KeePassXC. Any app that checks for write access before actually writing will fail the check. "Working" apps are actually doing things wrong by assuming write access.

[nbriche]

The GVFS patch seems to have been integrated to GNOME 3.34, included in, among others, Ubuntu 19.10. After a quick test, I can create, save and reopen a database on a SMB share.

[droidmonkey]

I am closing this issue based on the above testing.

[nbriche]

Apparently quick tests aren't enough. I've done more this morning, and while I can create and write to a new database, it still reopens in read-only. So no change it seems :(

Anybody else have a different result?

[sbrudenell]

This bug still exists.

• Ubuntu 19.10
• KeePassXC 2.4.3
• Used gnome's "Online Accounts" feature to connect both Google Drive and Nextcloud in gvfs.
• In both cases, I can create a database and save it to the gvfs mount, but when opening again, it opens read-only.

Read-only mode also seems broken to me. If I add entries to a database in read-only mode it succeeds. And closing the database also succeeds, losing the new entries, but giving no warning.

I can't find any documentation about read-only mode, so I don't understand its goals. Searching for "keepassxc read-only mode" just points to several versions of this bug.

I question whether an explicit read-only mode is worthwhile. It appears to cause far more problems than it solves. Most programs, including database programs, function just fine without it. They try to write a file and print an error if that fails.

It is frustrating that keepassxc's philosophy has been to avoid a built-in interface to cloud services, in favor of interfacing via things like gvfs, but this bug has made gvfs unusable for years.