Jump to content











Photo
* * * * * 1 votes

vMount

vhd

  • Please log in to reply
222 replies to this topic

#51 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 08 December 2018 - 05:53 PM

thank you very much misty



#52 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 08 December 2018 - 08:23 PM

Done some minor and easy updates.

 

The old "mount" command was incorrectly named as it more about assigning a drive letter to an existing ressource using windows API/services.

 

The new "assign" command will assign a logical drive letter to : a dos device, a volume, a samba share, a nfs export.

About the nfs export : (for now) it will only work on windows 7 ultimate and enterprise, windows 8 & 10 enterprise., if the "nfs services" windows featture is turned on.

 

Side topic but it is really a shame that NFS is only available on high end windows editions as it is really nice to have an alternative to the slow SMB protocol...

vmount v0.9 by erwan2212@gmail.com
vmount createfixed path_to_vhd size(MB)
vmount createdynamic path_to_vhd size(MB)
vmount createchild path_to_child path_to_parent
vmount attach path_to_vhd [NOLETTER]
vmount attach path_to_iso
vmount detach \\.\PhysicalDriveX
vmount detach disk_id
vmount
					
					
  • misty likes this

#53 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 08 December 2018 - 08:28 PM

@erwan.l
After a long break, I've started playing around with .vhd files again - in order to test SVBus. Your vMount tool will no doubt come in handy. One of many tools that have passed me by - I will look forward to testing it when I have some time. Looks great :thumbsup:

Thanks as ever for all of your development work. And sorry for my offtopic posts in this thread.

:cheers:

Misty

#54 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 08 December 2018 - 08:35 PM

@erwan.l
After a long break, I've started playing around with .vhd files again - in order to test SVBus. Your vMount tool will no doubt come in handy. One of many tools that have passed me by - I will look forward to testing it when I have some time. Looks great :thumbsup:

Thanks as ever for all of your development work. And sorry for my offtopic posts in this thread.

:cheers:

Misty

 

You starting to use vMount means you are most probably going to come with nice improvement and bug fixes  :lol:

Looking forward !

 

You are always welcome to hijack my threads  :thumbsup:

 

Erwan



#55 MJK

MJK

    Newbie

  • Members
  • 13 posts
  •  
    Ireland

Posted 09 December 2018 - 12:56 AM

As always, thank you for the support and updates.

 

Just two small queries, Erwan, re version 0.9:

 

  1. Is (or will) the old 'Mount' and 'UMount' options be discontinued?

 

  2. I think the old UMount command required just the 'X' syntax (no colon), whereas the new Remove command requires the 'X:' syntax?

 

  - Mike



#56 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 09 December 2018 - 11:14 AM

As always, thank you for the support and updates.

 

Just two small queries, Erwan, re version 0.9:

 

  1. Is (or will) the old 'Mount' and 'UMount' options be discontinued?

 

  2. I think the old UMount command required just the 'X' syntax (no colon), whereas the new Remove command requires the 'X:' syntax?

 

  - Mike

 

Hi Mike,

 

'mount' or 'umount' are no longer advertised but still supported for now.

The colon is necessary (and has always been) - actually internally, I add a '\'.

 

Being able to assign a letter to a device or volume is I believe a nice to have.

A next version will be able to enum devices and volumes.

 

Regards,

Erwan


  • Tokener likes this

#57 MJK

MJK

    Newbie

  • Members
  • 13 posts
  •  
    Ireland

Posted 10 December 2018 - 12:36 AM

Thanks, Erwan - I'll change the parsers here accordingly.

 

   - Mike



#58 MJK

MJK

    Newbie

  • Members
  • 13 posts
  •  
    Ireland

Posted 20 December 2018 - 09:56 PM

Just a small point, Erwan,

 

In version 0.9, when I run a DETACH command (eg, vmount64 detach \\.\PhysicalDrive2) when the previous UMOUNT has failed (and the DETACH should also fail), the error message I'm getting is:

 

detach_vhd:could not createfile
 
Maybe it should say something like "deletefile"?
 
Best regards,
  -Mike


#59 MJK

MJK

    Newbie

  • Members
  • 13 posts
  •  
    Ireland

Posted 21 December 2018 - 12:22 AM

Oh, another point I forgot to mention above:

 

I think that UMOUNT (ver 0.8) is working correctly when run under ADMIN rights, but, without Admin rights, it's throwing:

 

G: UMOUNT FAILED,5

 

If I can help with further tests on this, let me know.

 

  -Mike



#60 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 21 December 2018 - 12:15 PM

 

Just a small point, Erwan,

 

In version 0.9, when I run a DETACH command (eg, vmount64 detach \\.\PhysicalDrive2) when the previous UMOUNT has failed (and the DETACH should also fail), the error message I'm getting is:

 

detach_vhd:could not createfile
 
Maybe it should say something like "deletefile"?
 
Best regards,
  -Mike

 

 

There are 3 different syntax for detach - try using the path_to_vhd one and see what you get.

vmount detach \\.\PhysicalDriveX
vmount detach disk_id
vmount detach path_to_vhd

About umount, now renamed to remove (as umount was misleading), note that this one is about removing a logical drive letter and this, independently of the disk being physical or virtual.

It is there only for convenience and under some specific scenarios like : attach a vhd with no drive letter, THEN, choose which drive letter to assign to it.



#61 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 21 December 2018 - 12:18 PM

Oh, another point I forgot to mention above:

 

I think that UMOUNT (ver 0.8) is working correctly when run under ADMIN rights, but, without Admin rights, it's throwing:

 

G: UMOUNT FAILED,5

 

If I can help with further tests on this, let me know.

 

  -Mike

 

I am not surprised there and I am not sure I can do much about it.

To remove a logical drive letter, I use the very simple definedosdevice windows API which by design probably requires local admin rights.

As a whole, I am not sure an O.S would give such permission (whatever the API used) to remove a (system) logical drive assignement.



#62 MJK

MJK

    Newbie

  • Members
  • 13 posts
  •  
    Ireland

Posted 21 December 2018 - 12:43 PM

There are 3 different syntax for detach - try using the path_to_vhd one and see what you get.

vmount detach \\.\PhysicalDriveX
vmount detach disk_id
vmount detach path_to_vhd

About umount, now renamed to remove (as umount was misleading), note that this one is about removing a logical drive letter and this, independently of the disk being physical or virtual.

It is there only for convenience and under some specific scenarios like : attach a vhd with no drive letter, THEN, choose which drive letter to assign to it.

 

Thank you. OK, I'll try the other syntaxes. But, my only point here is that the text of the error-message seemed wrong - it says "createfile", and I think it might be more correct to say something like "deletefile"?

 

(The error-message WAS expected; it just seemed that maybe the incorrect message string was emitted by the code).

 

  - Mike



#63 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 21 December 2018 - 12:51 PM

Thank you. OK, I'll try the other syntaxes. But, my only point here is that the text of the error-message seemed wrong - it says "createfile", and I think it might be more correct to say something like "deletefile"?

 

(The error-message WAS expected; it just seemed that maybe the incorrect message string was emitted by the code).

 

  - Mike

 

Got it, sorry I missed your point :)

Actually, this is my code catching the error reported by the system.

In your case, it looks like the openvhd call is actually failing (wrong physicaldrive?).

try
'some code ...
'openvhd(path, returned_handled,...
'detachvhd(returned_handle, ...
except
on e:exception do writeln('detach_vhd:'+e.message);
end;


#64 MJK

MJK

    Newbie

  • Members
  • 13 posts
  •  
    Ireland

Posted 21 December 2018 - 01:04 PM

I am not surprised there and I am not sure I can do much about it.

To remove a logical drive letter, I use the very simple definedosdevice windows API which by design probably requires local admin rights.

As a whole, I am not sure an O.S would give such permission (whatever the API used) to remove a (system) logical drive assignement.

 

Thank you again!

 

Just to explain a little here (mainly for lurkers): I have an app which uses VMOUNT64 to open a VHD, the app then prepares various files inside the VHD, and it then runs another sub-app, which also accesses that VHD... The client wishes to run this whole "app/process" under non-admin rights.

 

As far as we know, everything else (all the attaching/mounting/etc in VMOUNT64, the entire sub-app, etc, etc) now works under non-admin rights, except for this UMOUNT/REMOVE command.

 

It's a bit interesting that MOUNT/ASSIGN does not require Admin rights, but UMOUNT/REMOVE does!!  ;-)

 

I had a quick look at the MS specs for that "DefineDosDevice" API: one comment in there: "Drive letters and device names defined at system boot time are protected from redefinition and deletion unless the user is an administrator". That might suggest that a newly-assigned Drive-letter does NOT require admin-rights, but I'm not very familiar with these Windows APIs, and reading-between-the-lines, etc!

 

Thank you - Très Bonnes Vacances

  - Mike



#65 MJK

MJK

    Newbie

  • Members
  • 13 posts
  •  
    Ireland

Posted 21 December 2018 - 01:17 PM

 

Got it, sorry I missed your point :)

Actually, this is my code catching the error reported by the system.

In your case, it looks like the openvhd call is actually failing (wrong physicaldrive?).

try
'some code ...
'openvhd(path, returned_handled,...
'detachvhd(returned_handle, ...
except
on e:exception do writeln('detach_vhd:'+e.message);
end;

This is a VERY minor matter, so apologies for raising it...

 

Hope this explains the circumstances... The commands I run are just:

   vmount64 attach xx.vhd
   vmount64 umount I:                           <-- This one fails, only because it does not have Admin rights (as discussed on a separate post)
   vmount64 detach \\.\PhysicalDrive2  <-- This one then produces that strange "createfile" error-message, presumably because the prior UMOUNT step has failed!
 
Mike


#66 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 21 December 2018 - 03:32 PM

 

This is a VERY minor matter, so apologies for raising it...

 

Hope this explains the circumstances... The commands I run are just:

   vmount64 attach xx.vhd
   vmount64 umount I:                           <-- This one fails, only because it does not have Admin rights (as discussed on a separate post)
   vmount64 detach \\.\PhysicalDrive2  <-- This one then produces that strange "createfile" error-message, presumably because the prior UMOUNT step has failed!
 
Mike

 

 

Interesting one and unexpected : umount touches on the logical drive so it should "normally" not affect the physicaldrive.

Now, it may be that MS virtualdisk API does not like this situation.

 

May be try the following thing :

-attach a VHD without a drive letter

-manually assign a drive letter

-manually remove a drive letter

-detach your VHD



#67 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 21 December 2018 - 08:23 PM

...

It's a bit interesting that MOUNT/ASSIGN does not require Admin rights, but UMOUNT/REMOVE does!!  ;-)

 

I had a quick look at the MS specs for that "DefineDosDevice" API: one comment in there: "Drive letters and device names defined at system boot time are protected from redefinition and deletion unless the user is an administrator". That might suggest that a newly-assigned Drive-letter does NOT require admin-rights, but I'm not very familiar with these Windows APIs, and reading-between-the-lines, etc!

...

 

Uhm, you are actually making a good point there and you are probably right (i.e no need for admin rights to assign a letter to a dos device).

 

For reference, i use the below code to assign or remove a drive letter to a dos device :

DefineDosDevice(DDD_RAW_TARGET_PATH,pchar(ParamStr(2)),pchar(ParamStr(3))
DefineDosDevice(DDD_REMOVE_DEFINITION,pchar(ParamStr(2)),nil)

So I am indeed using the same API to assign/remove a drive letter.

 

Let me do some experiment and see what I can do : now you got me challenged :)

 

EDIT (using my user account which is a local admin) and with 32bits (latest) version 0.9 on windows 8.1x64:

-assign (or mount) and remove (or umount) does work in standard console (i.e I dont need "Run as administrator" RAA /  elevated process)

-attach and detach does not work in a standard console (i.e i need RAA / elevated process)

 

In general, if this is a permission issue you should get error 5 ("access denied") or error 1314 ("a required privilege is not held by the client").

 

Also notice the difference below between dos devices (no need for admin rights) and mount points (requires admin rights):

vmount assign x: \device\harddiskX\partitionX
vmount assign x:\ \\?\Volume{GUID}\
vmount remove x:
vmount remove mount_point(e.g x:\ or c:\mount\)


#68 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 21 December 2018 - 09:00 PM

 

Just a small point, Erwan,

 

In version 0.9, when I run a DETACH command (eg, vmount64 detach \\.\PhysicalDrive2) when the previous UMOUNT has failed (and the DETACH should also fail), the error message I'm getting is:

 

detach_vhd:could not createfile
 
Maybe it should say something like "deletefile"?
 
Best regards,
  -Mike

 

 

This "could not createfile" was bothering me.

You should now get a more meaningful message (like "a required privilege is not held by the client" for example...).



#69 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 21 December 2018 - 09:05 PM

Hi!

The utility is great!

In Winpe 10 x64 works without problems, but in Winpe 10 x86 I received an error.

 

0948b1dfb6489907237088c9db4ae115.png

 

there was a bug in latest version 0.9 in the attach function.

now fixed.

download again.


  • Sergey Shikharev likes this

#70 Sergey Shikharev

Sergey Shikharev
  • Members
  • 2 posts
  • Location:Moscow
  •  
    Russian Federation

Posted 21 December 2018 - 10:13 PM

there was a bug in latest version 0.9 in the attach function.

now fixed.

download again.

Thanks, I will try.

 

PS. x86 checked, everything works well. Thank!


Edited by Sergey Shikharev, 21 December 2018 - 10:29 PM.


#71 MJK

MJK

    Newbie

  • Members
  • 13 posts
  •  
    Ireland

Posted 22 December 2018 - 12:16 AM

Interesting one and unexpected : umount touches on the logical drive so it should "normally" not affect the physicaldrive.

Now, it may be that MS virtualdisk API does not like this situation.

 

May be try the following thing :

-attach a VHD without a drive letter

-manually assign a drive letter

-manually remove a drive letter

-detach your VHD

Thanks, Erwan. I'll play around with your suggestions, and see what emerges... - Mike



#72 MJK

MJK

    Newbie

  • Members
  • 13 posts
  •  
    Ireland

Posted 02 January 2019 - 03:06 PM

Hello, Erwan,
 
Happy New Year!
 
I think I gave some mis-leading tests results previously, so I hope these observations are more accurate - all using the latest 0.90 build (Dec 21, 2018), 64-bit build, under Win-10:
 
1. Signed in with Admin rights. If use "attach xx.vhd NOLETTER". It works fine. It says:
 OpenVirtualDisk OK
 AttachVirtualDisk OK
 \\.\PHYSICALDRIVE2
 
The DISKS command then says:
 0 [] DISK TOSHIBA MK6475GSX      610480MB        SATA    NON-REMOVABLE   
 2 [5503DADD] DISK Virtual Disk    500MB           UNKNOWN NON-REMOVABLE
 
So, how do we then use MOUNT/ASSIGN to assign a drive-letter to the VHD? The MOUNT/ASSIGN options seem to require a syntax like "\device\harddiskX\partitionY", but I don't see the X/Y details from the above outputs, apart from the "2" in both cases?
 
If I try only "mount I: \device\harddisk2" (where the "2" is from the ATTACH output above), the response is "mount ok", but then, when I run PARTITIONS, drive "I:" is not listed?
 
Also:
  - If I try the exact same "mount" command (same drive-letter!) many times, it always says "mount ok"!
  - If I try "UMount I:", ït always says "umount ok" - even though drive I: is not available?
 
2. Signed in with Std (not Admin) rights. "attach xx.vhd", or "attach xx.vhd NOLETTER", both say: "OpenVirtualDisk OK - AttachVirtualDisk Failed, A required privilege is not held by the client".
 
Same results with 32-bit or 64-bit build of VMOUNT.
 
As I mentioned previously, I would like to be able to run this (and also UMOUNT/REMOVE and DETACH), without needing admin rights.
 
3. I get two slightly different syntaxes from the PARTITIONS command:
  - With Admin rights: C: [6GB-C] NTFS    \device\harddisk0\partition4 598888MB
  -      With Std rights: C: [6GB-C] NTFS    \Device\HarddiskVolume4      598888MB
 
4. Minor: If I use the new "ASSIGN/REMOVE" syntaxes, the responses still say "mount ok", "umount ok", etc.
 
5. Minor: If I run DETACH on a non-existent drive, it says "detach_vhd:could not createfile", which, as mentioned previously, seemed a bit weird!
 
6. If I can help with any of the above, let me know. Eg, if you have the APIs handy that you are using inside VMOUNT for the above (eg, DefineDOSDevice), I might (repeat, might!!) try to call a few of them directly, and, hopefully, help to progress these issues?
 
Best regards,
  - Michael K.


#73 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 02 January 2019 - 08:03 PM

...

 
The DISKS command then says:
 0 [] DISK TOSHIBA MK6475GSX      610480MB        SATA    NON-REMOVABLE   
 2 [5503DADD] DISK Virtual Disk    500MB           UNKNOWN NON-REMOVABLE
 
So, how do we then use MOUNT/ASSIGN to assign a drive-letter to the VHD? The MOUNT/ASSIGN options seem to require a syntax like "\device\harddiskX\partitionY", but I don't see the X/Y details from the above outputs, apart from the "2" in both cases?
 
If I try only "mount I: \device\harddisk2" (where the "2" is from the ATTACH output above), the response is "mount ok", but then, when I run PARTITIONS, drive "I:" is not listed?
 
Also:
  - If I try the exact same "mount" command (same drive-letter!) many times, it always says "mount ok"!
  - If I try "UMount I:", ït always says "umount ok" - even though drive I: is not available?
 
2. Signed in with Std (not Admin) rights. "attach xx.vhd", or "attach xx.vhd NOLETTER", both say: "OpenVirtualDisk OK - AttachVirtualDisk Failed, A required privilege is not held by the client".
 
Same results with 32-bit or 64-bit build of VMOUNT.
 
As I mentioned previously, I would like to be able to run this (and also UMOUNT/REMOVE and DETACH), without needing admin rights.
 
3. I get two slightly different syntaxes from the PARTITIONS command:
  - With Admin rights: C: [6GB-C] NTFS    \device\harddisk0\partition4 598888MB
  -      With Std rights: C: [6GB-C] NTFS    \Device\HarddiskVolume4      598888MB
 
4. Minor: If I use the new "ASSIGN/REMOVE" syntaxes, the responses still say "mount ok", "umount ok", etc.
 
5. Minor: If I run DETACH on a non-existent drive, it says "detach_vhd:could not createfile", which, as mentioned previously, seemed a bit weird!
 
6. If I can help with any of the above, let me know. Eg, if you have the APIs handy that you are using inside VMOUNT for the above (eg, DefineDOSDevice), I might (repeat, might!!) try to call a few of them directly, and, hopefully, help to progress these issues?
 
...

 

Hello Michael,

 

Happy new year to you as well.

And thanks as always for ytour contribution, bug reports and suggestions !

 

About admin rights (or not)

Attach/detach does require admin rights (or elevated privileges).

I use AttachVirtualDisk/DetachVirtualDisk api (virtdisk.dll).

I am pretty sure one cannot attach a virtual disk without elevated privileges.

 

About MOUNT (alias assign)

 

Always keep in mind that you "mount" (or rather assign a letter to) a partition (or volume).

You cannot assign a letter to a disk.

It works as follows:

vmount assign x: \device\harddiskX\partitionY
vmount assign x:\ \\?\Volume{GUID}\ 

X being the disk number starting at 0 and Y being the partitition number (for one particular disk) starting at 1.

vmount disks and vmount partititions should "normally" help you define X and Y (although I noted down that vmount partitions run as std user gives a different output).

Vmount assign x: \Device\HarddiskVolumeX should work as well thus less intuitive as X is then the volume number (for the whole system).

 

Note that one requires elevated privileges to assign a logical drive letter to a volume (with setvolumepoint API).

BUT one does not require elevated privileges to assign a logical drive letter to a dos device (with DefineDosDevice API).

 
Also, I reckon that assign/remove (or mount/umount) seem to report "ok" in many situations where it should report "failed" : i need to work on that.

 

Still about the MOUNT commannd

Latest version (from today .. ) introduced 2 new commands : vmount devices and vmount volumes which will list dos devices and volumes.

C:\>vmount devices
\device\Harddisk2\partition1
\device\Harddisk0\partition1
\device\Harddisk0\partition2
\device\Harddisk1\partition1

C:\>vmount volumes
\\?\Volume{e26e7b15-122a-11e7-82bf-806e6f6e6963}\

\\?\Volume{876ebd81-ce10-11e8-8334-94de80c2a41e}\
E:\

\\?\Volume{d43d21af-dd0c-11e8-8339-94de80c2a41e}\

\\?\Volume{e26e7b16-122a-11e7-82bf-806e6f6e6963}\
C:\

\\?\Volume{c3ccf19b-9cbc-11e8-8325-806e6f6e6963}\
D:\

About  "detach_vhd:could not createfile on non existing drive"

When you run vmount detach \\.\physicaldriveX, the first thing I do is actually to run createfile API against that drive to get a handle ... which I give to GetStorageDependencyInformation API (virtdisk) to get the actual vhd filename ... which I then pass on to DetachVirtualDisk (virtdisk).

I have introduced a slight change in latest vmount version : give it a try and let me know if you get a more meaningfull and proper error message.

 

EDIT

-In latest version, the partitions should be displayed the same (i.e \device\HarddiskX\partitionY) independently of your privileges.

 

Cheers,

Erwan



#74 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 06 January 2019 - 02:13 PM

Dear Erwan

testing your great tool I came to a command that does not work as I expected.

Maybe you have a clue.

vmount64_181221.exe assign X:\ \\?\Volume{26503745-1125-11e9-9e6f-0002a4b2c832}\
X:\ mount failed,87,Falscher Parameter

vmount64_181221.exe assign B:\Wert\ \\?\Volume{26503745-1125-11e9-9e6f-0002a4b2c832}\
B:\Wert\ mount ok

vmount64_181221.exe remove B:\Wert\
B:\Wert\ umount ok

assinging to an existing Folder works, but assigning to a (non-existing) Drive-Letter does not.

What am I doing wrong?

 

Regards   T.



#75 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 06 January 2019 - 03:26 PM

Dear Erwan

testing your great tool I came to a command that does not work as I expected.

Maybe you have a clue.

vmount64_181221.exe assign X:\ \\?\Volume{26503745-1125-11e9-9e6f-0002a4b2c832}\
X:\ mount failed,87,Falscher Parameter

vmount64_181221.exe assign B:\Wert\ \\?\Volume{26503745-1125-11e9-9e6f-0002a4b2c832}\
B:\Wert\ mount ok

vmount64_181221.exe remove B:\Wert\
B:\Wert\ umount ok

assinging to an existing Folder works, but assigning to a (non-existing) Drive-Letter does not.

What am I doing wrong?

 

Regards   T.

 

Hi ReTokener,

 

Thanks for your positive feedback.

 

I have noticed the following : if your volume already has a drive letter assigned to it, you may not be able to assign a new drive letter (but you will be able to assign it a folder).

Note that this limit does not seem to apply to dos devices : you can have multiple drive letters assigned to a dos device.

 

To assert this hypothesis, can you display the output of vmount volumes before you run vmount64_181221.exe assign X:\ \\?\Volume{26503745-1125-11e9-9e6f-0002a4b2c832}\ .

I suspect that \\?\Volume{26503745-1125-11e9-9e6f-0002a4b2c832}\ will actually have a drive letter already assigned to it.

 

Regards,

Erwan







Also tagged with one or more of these keywords: vhd

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users