Lock fails if vault contains .exe file that is accessed

[Rcmtr]

Hi,

I tested version 1.6.17 on a spare windows 10 PC before migrating older vaults and I noticed frequent lock problems when FUSE is used. After a lot of testing it appears that when a vault contains a .exe file in any folder/subfolder and that location is simply opened, it prevents the vault from locking. This is without running the .exe, just opening the folder is enough to cause the lock fail.

Force locking the vault sometimes (not always) prevents the lock fail from reoccurring in the future with that specific file, but only until this file is moved to another folder, or any parent folder is its filepath is renamed. In this case the .exe file can trigger more lock fails again.

This problem occurs only when FUSE is used and does not happen with WebDAV. Initially I thought it could be either Kaspersky or Malwarebytes causing the issue by scanning the .exe and then not releasing the file properly, but this kept happening even after I completely uninstalled both of the above. Windows defender is another possible cause but I haven’t been able to test this properly. Or it could be unrelated to antivirus software. The exact cause is unknown but the issue can be replicated with 100% accuracy and only .exe files trigger the lock fail.

By the way, fake .exe files do NOT trigger this. For example I changed the extension of a .txt file to .exe and copied it to vault without lock issues. But any real .exe file triggers the lock fail, if the location is opened/accessed before locking the vault.

Steps:

• New vault (FUSE / 1.6.17 / Windows 10) - LOCAL DISK (NO SYNC SOFTWARE WAS USED)
• Create Folder and/or Subfolder path in the vault
• Add any real .exe file to the subfolder (or folder)
• Close explorer and try to lock as usual → Fail
• If lock didn’t fail already, simply unlock the vault and browse to the location of the .exe file and just select the file (don’t run it). Close explorer and try to lock the vault as usual.

Could anyone please try to replicate this? (Use a new disposable vault)
Thank you

EDIT: It seems this is a known issue for more than a year (since Oct 2021):

Vault lock failed with FUSE/WinFSP

Today I upgraded Cryptomator to V1.6.1 and also tried it with FUSE / WinFSP. I noticed that when using FUSE, I cannot lock my vault. I always get the message, that there are open files or pending operations on the drive (even if I only opened the vault without changing anything). In the debug-log I found the problem: there is an exe-file in the root directory of the vault: 16:17:35.741 [fuseMount-5-main] WARN o.c.frontend.fuse.OpenFileFactory - Closing unclosed file OpenFile{path=/xyz.exe, c…

@Joe210 posted this back then.

[Joe210]

Unfortunately I also still have the same problem. Looks like the only workaround is not to use FUSE.

[Michael]

@Rcmtr

Steps:

• New vault (FUSE / 1.6.17 / Windows 10) - LOCAL DISK (NO SYNC SOFTWARE WAS USED)
• Create Folder and/or Subfolder path in the vault
• Add any real .exe file to the subfolder (or folder)
• Close explorer and try to lock as usual → Fail

I tried to reproduce that and did what you did.
My vault was instantly locked.
So I assume a process is accessing your exe file or the folder.
Maybe a scanner, index, whatever.
Have you checked (for example with Windows Process Explorer) if there is an app or process that is accessing the vault?

[Rcmtr]

Thanks Michael. I tried to check it via Process Explorer but could not identify the problem, but also I wasn’t sure what exactly I was looking for as it was the first time I used Process Explorer. I think @infeo had identified the issue before, or at least reproduced it in the thread below. Maybe he has any further info?

Vault lock failed with FUSE/WinFSP

I also checked this, by placing a single exe file into a vault. Everytime the vault is opend the exe file is executed, the lock afterwards fails und i have to force lock. I’ll have to look deeper into this.

[Joe210]

As I’m still interested in solving this topic, I tried this again using a fresh Windows 11 installation with Cryptomator 1.6.17 and the included WinFsp 2022.2 with the following steps:

1. Create a new vault, unlock it and reveal drive, then close Windows Explorer and lock the vault → no Problem
2. Unlock the vault again, reveal the drive, copy a .exe file to the vault, close Windows Explorer and lock the vault → still no Problem
3. Again, unlock the vault and reveal the drive, close Windows Explorer and lock vault → Lock failed

[Rcmtr]

If you 7zip the .exe (or better its entire folder in case of program installation folders) you can workaround this issue until it is resolved. It doesn’t have to be password protected or anything, it just needs to not be in .exe form. It is an inconvenience but at least you won’t have to worry about the integrity of your files due to force-locking the vaults.

[Joe210]

Its not possible for me to zip the file, because I use the .exe file for a small script to check file integrity of all files inside the vault. Of course, its possible to put the script and the exe file outside of the vault, but then its not possible to do this easy on every PC.

I attached the full logfile of the three steps I did above here: cryptomator0.log (497.7 KB)

[Joe210]

As I read in the Blog that Dokany support will be will officially deprecated with the upcoming release of v1.7.0, its important for, that this gets fixed.

Anyone working on this? @infeo already reproduced it in my old post, but looks that nothing happened since then?

[Silvernerd1]

Same problem here, but not with exe files, but with Word and Excel files.

Under computer management > open files appear files like

C:\Users\Michael\nnnnnnnnn\d\ND\QZG3OIGYLYNSSXR4FOBTXNDVZKZVBL
C:\Users\Michael\nnnnnnnnn\d\QK\0U6PQODTÖZZBQ3XHQQGLADAETLHZIC\EIMYYCh_—hu7XGthl-lTZBUqRROMmkpBPByOKLb1Söw:=.c9r
C:\Users\Michael\nnnnnnnnn\d\QK\DUGPQD DTÖZZBQ3XHQQGLADAETLHZIC\QVQZQMul6w79qY0pN8utLßlCallclem3UdUoZtWlemeOM=.c9r

The number of open files becomes smaller and smaller over time, but never reaches 0.

Seems to be a difficult problem, if it is still unresolved after so long time. Does not make good feelings since Dokany support was discontinued and WinFSP is the favored volume type …