Mirror.exe does not work in Docker container

[martin5233]

Environment

• Windows version: Windows 10 21H2
• Processor architecture: amd64
• Dokany version: 2.0.5.1000
• Library type (Dokany/FUSE): Originally FUSE, but reproducible with Dokany directly as well

Check List

• [x] I checked my issue doesn't exist yet
• [x] My issue is valid with mirror default sample and not specific to my user-mode driver implementation
• [x] I can always reproduce the issue with the provided description below.
• [x] I have updated Dokany to the latest version and have reboot my computer after.
• [x] I tested one of the last snapshot from appveyor CI

Description

I am trying to run Dokany inside a Docker container with Windows Server 2019. My actual use case uses the fuse interface, but I was able to reproduce the issue using the mirror sample.

I am using the following simple Dockerfile:

FROM mcr.microsoft.com/windows:ltsc2019
RUN mkdir C:\temp
COPY mirror.exe C:/temp
COPY DokanSetup.exe C:/temp
RUN C:\temp\DokanSetup.exe /install /quiet
RUN C:\temp\mirror.exe -l C:\temp -r m /d /s /e

The output of running the mirror executable via docker is attached. I found the related issue #834, which was closed with the intention to open a new one, which I didn't find.

Logs

I have attached the output of mirror.log. DbgView did not output anything, when started with DbgView /K.

[Liryna]

Hi @martin5233 , the logs seems to be missing.

[martin5233]

Hi @Liryna,

I'm quite sure I attached them, but anyway I attached them a second time.

mirror.log

[Liryna]

Can't install driver This indeed looks like https://github.com/dokan-dev/dokany/issues/834. Have you tried the steps that @xgcssch did ?

[martin5233]

Hi @Liryna,

I have tried to follow the steps in #834.

pnputil -i -a dokan.inf gives me the same as in that issue:

Microsoft PnP Utility

Processing inf :            dokan.inf
Adding the driver package failed : The data is invalid.


Total attempted:              1
Number successfully imported: 0

Then I copied the contents of the dokan.zip package into the container and started a powershell inside. In this shell I changed to the Release\driver directory and ran pnputil /add-driver dokan.inf /install with the same result as in #834:

Microsoft PnP Utility

Failed to add driver package: Missing or invalid driver package specified.

Total driver packages:  0
Added driver packages:  0

However dokanctl.exe /i d gave me something different:

Driver path: 'C:\Windows\system32\drivers\dokan2.sys'
Installing driver...
Error the file 'C:\Windows\system32\drivers\dokan2.sys' does not exist.

I have no idea, how I can get DbgView working inside the container as it seems to require its GUI. I attempted to run it on the command line passing /l to log the output to a file, but it returned immediately with no visible effect. Any ideas how to debug this further?

[Liryna]

For dokanctl to work you need the driver to be copied at the location it says. Looks like it is missing right now. Can you try to copy it there and redo the command ?

I also haven't tried to run it in docker and I don't have the environment right now to try.

[martin5233]

I wasn't aware of this. After copying the .inf and the .sys file into C:\Windows\system32\drivers\dokan2.sys I got the same as in #834:

PS C:\temp\Release> .\dokanctl.exe /i d
Driver path: 'C:\Windows\system32\drivers\dokan2.sys'
Installing driver...
DokanServiceInstall: Service (Dokan2) installed
DokanServiceControl: Service (Dokan2) started
DokanServiceInstall: Service (Dokan2) started
Driver installation succeeded!

However a subsequent call to sc query dokan or sc query dokan2 returns nothing at all.

[martin5233]

I also tried sc query type=driver, which lists a lot of drivers, but nothing related to Dokan. The same happens when invoking sc query type=service

[Liryna]

I believe Microsoft docker does not allow installing and starting drivers inside a container. What could be possible but not yet supported, is to have the driver installed on the host and have the userland filesystem (your implementation or mirror) running inside the container. The driver would monitor the active containers (Silo) through standard API and "attach" himself to them so the userland process can communicate with. Server silo will only work for lightweight mode which is enabled using --isolation=process option.