Getting "Lock failed" after opening vault in Nautilus

I’m finding that I can no longer lock my vault after accessing it from the Nautilus file browser.

To reproduce I do the following:

  1. Open Cryptomator and unlock my vault
  2. Press the Reveal Drive button (opens a Nautilus window on the folder)
  3. Open a subfolder within the vault
  4. Close the Nautilus window
  5. Try to lock the vault

Expected results: The vault should lock

Actual results: Cryptomator opens a “Lock failed” dialog. Cryptomator does not lock the vault even after pressing the “Force Lock” button. The only way I’ve found to close Cryptomator and lock the vault is by forcing Cryptomator to quit using kill -9 $CRYPTOMATOR_PID.

Additional information: The problem appears to be specific to Nautilus. I could not reproduce the problem by accessing the vault from the shell, nor by reading files from other applications.

I’m inclined to file a bug on this, but I’m not sure if the bug should be filed against Cryptomator or Nautilus. Any input as to reporting the problem? Is there anything else I should check before filing a bug report?

I’m on Fedora 36 and have Nautilus 42.2 installed. Cryptomator version is 1.6.12.

Hey and welcome to the Cryptomator Community :slightly_smiling_face:,

Tried to reproduce your problem with Nautilus 42.2 on Manjaro but can not reproduce it.

Can you please check with lsof /PATH_TO_YOUR_MOUNTED_VAULT if maybe another process is accessing the vault too?

I’ve tried that. sudo lsof | grep $PATH_TO_MOUNTED_VAULT produces no output.

Just to be sure:

For example, if you read the mounted vault path here

Open Nautilus as mentioned in your issue description and then do in this case
lsof /home/julian/Crypted

Is a process still accessing the vault?

No, it isn’t. The only time I see the mount point in lsof output is if I have a terminal on that path (presumably it would list Nautilus too if I opened it while Nautilus was actively reading or writing).

I do see another thing just now, which I don’t recall seeing before:

$ sudo lsof |grep .local/share/Cryptomator/mnt/cryptomatorlsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
      Output information may be incomplete.
lsof: WARNING: can't stat() fuse.joplin-desktop file system /tmp/.mount_joplinhe4f3f
      Output information may be incomplete.
lsof: WARNING: can't stat() fuse.cryptomator file system /tmp/.mount_cryptoKIaJFs
      Output information may be incomplete.
lsof: WARNING: can't stat() fuse.fusefs1445802527 file system /home/jhaiduce/.local/share/Cryptomator/mnt/cryptomator
      Output information may be incomplete.

The above was all written to standard error and not filtered by grep since I didn’t redirect stderr to the pipe. The last warning references the mount point of my vault.

Possibly related behavior, but slightly harder to reproduce:

  • I often notice that Nautilus stalls when opening directories inside my vault. Usually moving the Nautilus view to a directory outside the vault and then opening the vault again fixes it, but it’s annoying nonetheless.
  • If I open a Gnucash file in my vault while the vault is open in Nautilus and then make some edits to the file, Gnucash occasionally will stall in the process of saving the file. At that point I am unable to get Gnucash to shut down, even with kill -9. The only way I’ve found to recover at that point is to log out and log back in. So far I’ve only seen Gnucash behave this way is when the vault has been opened in Nautilus during the same session.

Also a bit of background information, I first noticed all three problems about 2 weeks ago, after a couple years of using Cryptomator on the same machine with the same vault. I first saw the problem on a slightly older version of Cryptomator (I think it was 1.6.10) and upgraded Cryptomator to 1.6.12 after I encountered these problems.