Help with WinFSP within a Windows Docker Container
Keith Kaminski
- memfs-dotnet: cannot mount file system
- memfs-dotnet: The service MemfsService has failed to start (Status=e0434f4d).
Bill Zissimopoulos
Keith, hello:
It is my understanding that container technology on Windows is fairly new. Little system-level documentation on the subject is available.
If you are looking to load the driver inside the container: I believe that this is not possible, because both the host OS and the container share the kernel; since the container does not have its own kernel it cannot load drivers. (An alternative if you want isolation might be to use a VM instead of a container.)
If you are looking to load the driver in the host and access it from a user mode file system: this may be possible, but is not a scenario that WinFsp currently supports. I am actually interested to explore this scenario, but the truth is that Microsoft has little documentation available on the subject. (There are a number of new kernel “silo” calls that Microsoft is slowly documenting.)
So unfortunately I do not have a better answer than this is not currently supported, but I am hoping to support it in the future.
Bill
Hello,
We have code currently running in Windows Docker containers that accesses files on a network file share. We'd like to use WinFsp within those containers to install our own user mode file system to handle all those requests to the NFS.
To test something simple, we took the memfs-dotnet code and built a C# console app that targets .NET Framework 4.7.2. After verifying that it worked on a local development box, we attempted to get it working within a docker container. The dockerfile we used is pretty straightforward and I have attached a sample of it here.
We then navigated to the app folder within our container and executed the following command: `memfs-dotnet.exe -t -1 -n 1024 -s 16777216 -m Y: -d -1 -D "C:\app\driverdebug.log"'. And yes - we were just testing a drive letter mount as opposed to an NFS to start with. After roughly 10 seconds or so, the application simply closes. Nothing is written to the configured debug log file. We do, however, see two relevant messages in the Event Log:
1. memfs-dotnet: cannot mount file system
2. memfs-dotnet: The service MemfsService has failed to start (Status=e0434f4d).
We spent a bit of time trying to debug, and we were able to determine that the following line in the FileSystemHost was returning STATUS_DRIVER_UNABLE_TO_LOAD. We then tried to enable mixed mode debugging to step into the C++ code, but it doesn't look like the PDBs included in the WinFsp installer have source maps so we didn't have much success.
We also tried to start the driver from the command line using "sc start winfsp". This does not appear to work, though, and we get the following:
SERVICE_NAME: winfsp
TYPE : 2 FILE_SYSTEM_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 1077 (0x435)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :
The error code 1077 is just "No attempts to start the service have been made since the last boot.". I can't find anything in the event logs or any other indication of failure.
We are sort of at a loss about how to continue troubleshooting. It may be some limitation of Windows Docker containers that we're running into... but we are hopeful that we can somehow get this to work! For reference, I have also attached the results of running diag.bat in the container.
Thanks.
- Keith Kaminski
--
You received this message because you are subscribed to the Google Groups "WinFsp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
winfsp+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/winfsp/5dba8bc1-e8bf-4aed-8ebe-2d943794d263%40googlegroups.com.
Tomas Dalebjörk
--
Bill Zissimopoulos
Keith:
As a follow up to my earlier reply I dumped the imports of the Ntfs.sys driver (the driver that implements NTFS) using `dumpbin /imports ntfs.sys`. I found that there is only a single Silo call that Ntfs.sys uses (IoGetSilo). So there is a small chance that the following may work.
- Install WinFsp on the host computer. This is required to get the WinFsp kernel driver installed on the host OS kernel.
- Start the WinFsp kernel driver (e.g. use `sc start winfsp`)
- Install WinFsp on the container. This is required to get the WinFsp usermode DLL that knows how to interface with the kernel driver.
- Try to run your file system.
This is under the (admittedly strained) assumption that the Silo functionality is implemented in such a way as to be normally transparent to kernel mode drivers. My rationale is:
- It is conceivable that the new “Silo” functionality “virtualizes” the NTOS Object Manager name space in a manner transparent to drivers.
- The NTFS driver (the most important file system driver on Windows) does not appear to have a lot of knowledge of Silos.
If you try this experiment, please let me know of the outcome.
Hello,
We have code currently running in Windows Docker containers that accesses files on a network file share. We'd like to use WinFsp within those containers to install our own user mode file system to handle all those requests to the NFS.
To test something simple, we took the memfs-dotnet code and built a C# console app that targets .NET Framework 4.7.2. After verifying that it worked on a local development box, we attempted to get it working within a docker container. The dockerfile we used is pretty straightforward and I have attached a sample of it here.
We then navigated to the app folder within our container and executed the following command: `memfs-dotnet.exe -t -1 -n 1024 -s 16777216 -m Y: -d -1 -D "C:\app\driverdebug.log"'. And yes - we were just testing a drive letter mount as opposed to an NFS to start with. After roughly 10 seconds or so, the application simply closes. Nothing is written to the configured debug log file. We do, however, see two relevant messages in the Event Log:
1. memfs-dotnet: cannot mount file system
2. memfs-dotnet: The service MemfsService has failed to start (Status=e0434f4d).
We spent a bit of time trying to debug, and we were able to determine that the following line in the FileSystemHost was returning STATUS_DRIVER_UNABLE_TO_LOAD. We then tried to enable mixed mode debugging to step into the C++ code, but it doesn't look like the PDBs included in the WinFsp installer have source maps so we didn't have much success.
We also tried to start the driver from the command line using "sc start winfsp". This does not appear to work, though, and we get the following:
SERVICE_NAME: winfsp
TYPE : 2 FILE_SYSTEM_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 1077 (0x435)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :
The error code 1077 is just "No attempts to start the service have been made since the last boot.". I can't find anything in the event logs or any other indication of failure.
We are sort of at a loss about how to continue troubleshooting. It may be some limitation of Windows Docker containers that we're running into... but we are hopeful that we can somehow get this to work! For reference, I have also attached the results of running diag.bat in the container.
Thanks.
- Keith Kaminski
--
Keith Kaminski
Bill Zissimopoulos
Understood.
I will open up an issue on GitHub asking for container support and mark it as enhancement request. This will let me track it and hopefully add the functionality in the future.
Bill
On 10/14/19, 10:40 AM, win...@googlegroups.com on behalf of Keith Kaminski wrote:
Thanks for the reply, Bill. Unfortunately, the setup you proposed is how I was testing everything by default anyway. My "host" is my developer environment that has WinFSP installed already.
--
You received this message because you are subscribed to the Google Groups "WinFsp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
winfsp+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/winfsp/7b54ce2b-de66-4481-8a8b-6ecfea7ba8f8%40googlegroups.com.
Bill Zissimopoulos
To view this discussion on the web visit
https://groups.google.com/d/msgid/winfsp/F9327BA7-5989-4076-87E8-E4C097F0665B%40navimatics.com.