VHDX mounting over network share

[David Balažic]

Hi!

I am troubleshooting a problem with mounting a VHDX from a netowrk share.

Short: it does not work

Long:
I have a Windows Image Backup made from Windows 10, stored on my Windows 2012R2 server.
The files are on a ReFS StorageSpaces mirror.

They can not be mounted on win2012 or remotely. I found out this is because of the FileIntegrity flag on the VHDX files:

In powershell: Get-Item .\Esp.vhdx | Get-FileIntegrity
Prints:

FileName Enabled Enforced
----------- ------- --------
Esp.vhdx True True

Turning the falg off makes it work, but I don'w want to loose the protection it offers (isia checksumming thing, if a it detects a corruption, it loads the copy from the other mirror and fixes it).

Turning it on again takes a long times, as it has to compute the checksum again and that takes long on big VHDX files.

So I tried ImDisk, to see if it works even with the integrity flag on. It does not.

I tried it on a Windows 7 32 bit PC, ImDisk Toolkit version 20200609

When trying to mount the esp.vhdx (it is the smallest to test), with "MountImage File", everything works until I click OK in the ImDisk dialog, the I get an error : An error occured while the mounting. Please check the parameters.

If I copy the esp.vhdx file to local HD (to the desktop), then I can mount it with no problems.

This is with integrity flag turned of on the file.

[v77]

When a vhdx file is mounted with the GUI, it creates a process (DiscUtilsDevio.exe) in the session 0, that is, as the "System" user. Perhaps this is a permission issue?
I am not an expert in network shares, but if the GUI is able to "see" the image file and not this process, this could explain the issue.

[KeyCat]

I experiencing the same problem when trying to mount images (tested VHD/VDI images) over a (password protected) network share so I also think the problem is a permission issue as you mention.

If I copy the image file/s to an public SAMBA share (ie no password) it works just fine!

I'm running Windows 7 SP1 x64 and ImDisk Toolkit version 20200727 and it fails trying to mount an image from a XP shared folder but as mentioned works fine if the share is public.

[KeyCat]

Did some more testing and now I'm even more confused ;)

As I mentioned above if I try to mount a VHD or VDI file on a XP shared folder it fails with "An error occured while the mounting. Please check the parameters."

If I copy the same VHD/VDI files to a public samba share it works just fine and I can mount them without issues.

Here comes the strange part....I just tried to mount a RAW IMG file on the the same XP shared folder and it worked without issues??

Strange it works with IMG files but not with VHD/VDI files???

[v77]

IMG files are mounted directly by the driver (through a call to imdisk.exe). VHD/VDI files are mounted by DiscUtilsDevio.exe, which is a user mode process started in the session 0 with the "System" user privileges. So privileges can be different.

[KeyCat]

Thanks for clarifying!

Just a FYI: Found some more info from Olof about DiscUtilsDevio.exe here http://reboot.pro/topic/15593-faqs-and-how-tos/ and tested to mount a VHD from the shared folder directly from CLI with success...

C:\Program Files\ImDisk Toolkit>DiscUtilsDevio /mount=I: /filename="\\GIGA-C2D\d\Virtual Machines\Windows 98 SE - Test\HDD0.vhd" /readonly
Opening image \\GIGA-C2D\d\Virtual Machines\Windows 98 SE - Test\HDD0.vhd
Image type class: DiscUtils.Vhd.Disk
Partition table class: DiscUtils.Partitions.BiosPartitionTable
Image virtual size is 17179869184 bytes
Image sector size is 512 bytes
Partition table found.
Using partition 1
Used size is 17174352384 bytes
Read-only mode.
Opening image file and mounting as virtual disk...
Virtual disk created. Press Ctrl+C to remove virtual disk and exit.

Maybe there are technical reasons to start DiscUtilsDevio.exe with "System" user privileges instead of starting it as current user?

[v77]

DiscUtilsDevio.exe is started in session 0 to avoid being killed when the system shutdown. Otherwise this can make the system stuck.

Here, we can see that the driver retrieves the current user's privileges.
That's interesting. I will dig that.

[Olof Lagerkvist]

The driver creates a thread that impersonates the token of the calling process. That makes it possible for it to reach network shares in the same way as the calling process has access to. A similar thing can be done in user mode using a named pipe that calls a session 0 service which then calls ImpersonateNamedPipeClient.