Empty vault when mounting point is on same file system

Jeffr · December 28, 2020, 2:56am

Hello,

d:\VAULT1 is my root vault directory. I would like to mount it on d:\DATA1, an empty directory not currently in use by any process (just created). I go to the options and set the mounting point then unlock. There is no error reported but the directory d:\DATA1 is empty.

I get a warning in the log file:

13:50:36.772 [App Background Thread 006] INFO  com.dokany.java.DokanyMount - Dokany API/driver version: 140 / 400
13:50:42.776 [App Background Thread 006] WARN  o.c.frontend.dokany.MountFactory - Mounting timed out.
13:50:42.777 [App Background Thread 006] INFO  o.c.ui.unlock.UnlockWorkflow - Unlock of 'VAULT1' succeeded.

When I choose a mounting point on another drive, like c:\DATA1, it works fine and I see all my files.

Both c: and d: are NTFS on my system. I have Windows 10 and I use Cryptomator v. 1.5.1.1.

Please help.

infeo · December 29, 2020, 3:25pm

This indicates it might be also related to the following issue on our tracker:

github.com/cryptomator/cryptomator

Vault mounted with Dokany is unmounted directly or shortly after unlock

opened 08:20PM - 24 Nov 20 UTC

closed 11:24PM - 27 Jan 21 UTC

demdante

type:upstream-bug os:windows mount:dokany

### Description As the title says, when Cryptomator is configured so that it …launches at startup and the vault is configured to "reveal" on launch, the drive does not successfully mount. I have to lock the vault, and then re-unlock it for the drive to mount, so there is a pretty simple work around, but I figured it was still worth reporting. ![cryptomator](https://user-images.githubusercontent.com/64720591/100143197-df34a300-2e8c-11eb-923d-84a794edd84d.gif) ### System Setup * Operating system and version: Windows * Cryptomator version: 1.5.10 * Volume type: Dokany ### Steps to Reproduce 1. Enable "Launch Cryptomator on system start" configuration in settings 2. Enable "Unlock vault when starting Cryptomator" configuration and select "Reveal Drive" for the "After successful unlock" setting in the "vault options" 3. Restart the computer 4. After the computer restarts, the vault will not have mounted in file explorer #### Expected Behavior The drive should successfully mount and be available in file explorer #### Actual Behavior The drive is not displayed or available in file explorer #### Reproducibility Always/Intermittent ### Additional Information [Cryptomator.zip](https://github.com/cryptomator/cryptomator/files/5592429/Cryptomator.zip)

@Jeffr Cann you also gather an event capture (described here while you mount the vault? (using the failing mount point) You can send me the capture via a PM.

Jeffr · January 15, 2021, 8:11pm

Thank you for your reply. This is what I’ve done:

Created a fresh test vault.
For this vault, activated the “Custom mount options” with the line: " --options CURRENT_SESSION,STD_ERR_OUTPUT --thread-count 5 --timeout 10000 --allocation-unit-size 4096 --sector-size 4096"
Activated “Debug logging”
Created in my home folder a file called “StartCryptomatorWithDokanDebug.cmd” and pasted the following into the file: "“C:\Program Files\Cryptomator\Cryptomator.exe” 2>“C:\Users\admin\dokan.log” 1>“C:\Users\admin\cryptomator.log”
Closed Cryptomator
Lauched StartCryptomatorWithDokanDebug.cmd
Unloked my vault (VAULT1)
On revealing the folder “j:\DATA1” is empty (this is the error).
Locked VAULT1

RESULTS

This what appears in the logfile:

20:36:53.785 [main] INFO  org.cryptomator.launcher.Cryptomator - Starting Cryptomator 1.5.11 on Windows 10 10.0 (amd64)
20:36:53.795 [main] DEBUG org.cryptomator.logging.DebugMode - Debug mode enabled
20:36:53.796 [main] DEBUG org.cryptomator.launcher.IpcFactory - [Client] Reading IPC port from C:\Users\admin\AppData\Roaming\Cryptomator\ipcPort.bin
20:36:53.796 [main] DEBUG org.cryptomator.launcher.IpcFactory - [Client] Connecting to port 50244...
20:36:53.904 [RMI TCP Connection(4)-127.0.0.1] DEBUG o.c.launcher.IpcProtocolImpl - Received launch args: 
20:36:53.905 [main] INFO  org.cryptomator.launcher.Cryptomator - Found running application instance. Shutting down...
20:36:53.906 [ShutdownTasks] DEBUG org.cryptomator.common.ShutdownHook - Running graceful shutdown tasks...
20:36:53.915 [JavaFX Application Thread] WARN  o.cryptomator.ui.fxapp.FxApplication - has visible stages: true
20:36:53.931 [JavaFX Application Thread] DEBUG o.cryptomator.ui.fxapp.FxApplication - Showing MainWindow
20:37:06.958 [JavaFX Application Thread] DEBUG o.cryptomator.ui.fxapp.FxApplication - Showing UnlockWindow for VAULT1
20:37:06.959 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - stop recording stats
20:37:14.054 [JavaFX Application Thread] TRACE o.c.ui.unlock.UnlockController - UnlockController.unlock()
20:37:14.057 [App Background Thread 006] DEBUG o.cryptomator.cryptofs.ReadonlyFlag - Vault opened for read and write.
20:37:34.878 [JavaFX Application Thread] TRACE o.c.ui.unlock.UnlockController - UnlockController.unlock()
20:37:34.881 [App Background Thread 006] DEBUG o.cryptomator.cryptofs.ReadonlyFlag - Vault opened for read and write.
20:37:35.149 [App Background Thread 006] DEBUG o.c.c.common.MasterkeyBackupHelper - Verified backup file: J:\VAULT1\masterkey.cryptomator.199232D9.bkup
20:37:35.150 [App Background Thread 006] DEBUG o.c.c.m.CustomMountPointChooser - Successfully checked custom mount point: J:\DATA1
20:37:35.151 [App Background Thread 006] DEBUG o.c.frontend.dokany.MountFactory - Mounting on J:\DATA1: ...
20:37:35.151 [App Background Thread 006] INFO  com.dokany.java.DokanyMount - Dokany API/driver version: 140 / 400
20:37:35.648 [JavaFX Application Thread] DEBUG org.cryptomator.common.CommonsModule - Starting App Background Thread 011
20:37:41.153 [App Background Thread 006] WARN  o.c.frontend.dokany.MountFactory - Mounting timed out.
20:37:41.154 [App Background Thread 006] INFO  o.c.ui.unlock.UnlockWorkflow - Unlock of 'VAULT1' succeeded.
20:37:41.183 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - start recording stats
20:37:45.932 [JavaFX Application Thread] TRACE o.c.u.unlock.UnlockSuccessController - UnlockSuccessController.revealAndClose()
20:38:03.248 [JavaFX Application Thread] DEBUG o.cryptomator.ui.fxapp.FxApplication - Start lock workflow for VAULT1
20:38:03.249 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - stop recording stats
20:38:03.249 [JavaFX Application Thread] INFO  org.cryptomator.ui.lock.LockWorkflow - Lock of VAULT1 succeeded.
20:38:03.250 [JavaFX Application Thread] DEBUG o.c.common.vaults.VaultStats - stop recording stats
20:38:04.675 [JavaFX Application Thread] DEBUG o.cryptomator.ui.fxapp.FxApplication - Showing Preferences
20:38:07.416 [JavaFX Application Thread] DEBUG org.cryptomator.logging.DebugMode - Debug mode disabled
20:38:08.421 [App Scheduled Executor 02] INFO  o.c.common.settings.SettingsProvider - Settings saved to C:\Users\admin\AppData\Roaming\Cryptomator\settings.json

In Windows event viewer > Windows logs > System, I get 36 information events at 20:27:35 for dokan1 - but I cannot upload the file here because I get the message “Sorry, new users can not upload attachments.” So let me know if you want me to pass it to you by other means.

Thanks.

Jeffr · February 6, 2021, 12:14am

Hi.

I would greatly appreciate some help on the problem raised.

I would also like to know: has anyone successfully mounted a vault on the same file system, for instance mounting d:\VAULT1 on d:\DATA1? Or do you have the same problem (vault mounted but empty)? So I would know if this is a problem with the product itself or rather with my configuration.

Cheers.

Michael · February 6, 2021, 8:17am

Hi.
I tried to reproduce that but couldn’t.
Vault: d:\somefolder\test
Mountpoint: d:\somefolder\custommountpoint
Works like a charm on my system. Vault is not empty
OS: Windows 10 Pro 20H2
Dokany: 1.4.1.100

Jeffr · February 6, 2021, 6:18pm

Thanks so much , this gives me a clue at least. I am going to investigate further.

Jeffr · February 9, 2021, 8:26pm

Ok. It turns out that Windows Explorer creates a conflict. I noticed that when I close all my Win. Ex. windows, everything works fine. I can mount the drive and reveal the files in it. But if I am currently having a Win. Ex. window open, it does not work most of the time.

So I tried to refine the diagnostic to determine exactly when it fails, having a Win. Ex. window open.

Remember, my vault is in J:\VAULT1. It turns out that:

If I open Windows Explorer and just select the J: drive on the left pane, the mounting works fine.
Now if I just expand the content of the J: drive on the left pane, it stops to work. No need to even explore the content of the J:\VAULT1 folder to make the mounting fail.
Same result (failure) if I now collapse the J: drive in the left pane and go to another drive letter. At this point one needs to close Windows Explorer to make things work again.

So now I guess I have a workaround, but the question still remains: is that an expected behavior?

Can someone reproduce the same pattern or is it again something to do with my configuration?

Cheers.

Michael · February 11, 2021, 5:35pm

Cannot reproduce that either (still on 1.5.11 as you are).

To be more precise to your case, I moved the vault directly to root.
“d:\testvault”.
The mountpoint folder is also in root now
“d:\custommountpoint”

Having the Windows Explorer open, D expanded, D not expanded, even the testvault folder expanded or the custommountpoint expanded. Does not have any negative effect or mount timeout.

infeo · February 11, 2021, 8:15pm

The problem you are experiencing might be related to the following issue on our bugtracker:

Maybe some application (explorer, plugin, anything), opens provisionally a handle to the mount directory, which locks the directory and prevents the Dokany driver from transforming the directory into a reparse point.

Jeffr · February 13, 2021, 1:41am

Thanks Michael, Infeo for the input. Indeed the open handles are the cause.

I have just tested with the sysinternals/handle tool and I could verify that as soon as I expand my J: drive in Windows Explorer, Windows opens not 1 but 2 handles for each subdirectory therein. Then, I only need to close the two handles opened on the mounting point for things to work again.

I don’t know why my Windows Explorer behaves this way on my system. Maybe it’s some other product I’ve installed, but I can’t be sure.

Anyway, this thread can be closed as far as I am concerned.

Cheers.