Recent 16.x versions can't mount a writeable NTFS Disk

[btmp]

On more recent versions of VMware Workstation I've found that I cannot mount NTFS formatted drives as writable. Mounting the same drives as READ ONLY works fine.

This includes VMware-workstation-full-16.2.2-19200509 btw

VMware-workstation-full-16.1.2-17966106 was the last version to properly mount NTFS formatted drives as writable. Mounting them as read-only still works but that's not at all helpful when trying to ADD files to the disk or EDIT existing files (eg the registry of windows while troubleshooting found in "C:\Windows\System32\Config" etc)

The Drives show up as ? in explorer and the only related Windows Event Logs I've come across are entries like these each time I attempt to mount it with a timestamp that 'almost' matches the mount attempt

Spoiler

The system failed to flush data to the transaction log. Corruption may occur in VolumeId: ??, DeviceName: \Device\vstor2-mntapi20-shared-99A22C8D000010000000000001000000.

           Failure status: The I/O request was canceled.

           Device GUID: {00000000-0000-0000-0000-000000000000}
           Device manufacturer:
           Device model:
           Device revision:
           Device serial number:
           Bus type: <unknown>

           Adapter serial number:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Ntfs" Guid="{3ff37a1c-a68d-4d6e-8c9b-f79e8b16c482}" />
  <EventID>140</EventID>
  <Version>1</Version>
  <Level>3</Level>
  <Task>0</Task>
  <Opcode>0</Opcode>
  <Keywords>0x8000000000000008</Keywords>
  <TimeCreated SystemTime="2022-01-19T20:28:58.7013511Z" />
  <EventRecordID>81</EventRecordID>
  <Correlation />
  <Execution ProcessID="4" ThreadID="5792" />
  <Channel>System</Channel>
  <Computer>NT</Computer>
  <Security UserID="S-1-5-18" />
  </System>
- <EventData>
  <Data Name="VolumeIdLength">2</Data>
  <Data Name="VolumeId">??</Data>
  <Data Name="DeviceNameLength">63</Data>
  <Data Name="DeviceName">\Device\vstor2-mntapi20-shared-99A22C8D000010000000000001000000</Data>
  <Data Name="Error">0xc0000120</Data>
  <Data Name="DeviceGuid">{00000000-0000-0000-0000-000000000000}</Data>
  <Data Name="VendorIdLength">0</Data>
  <Data Name="VendorId" />
  <Data Name="ProductIdLength">0</Data>
  <Data Name="ProductId" />
  <Data Name="ProductRevisionLength">0</Data>
  <Data Name="ProductRevision" />
  <Data Name="DeviceSerialNumberLength">0</Data>
  <Data Name="DeviceSerialNumber" />
  <Data Name="BusType">0</Data>
  <Data Name="AdapterSerialNumberLength">0</Data>
  <Data Name="AdapterSerialNumber" />
  </EventData>
  </Event>

I've also tried different variations such as creating a brand new NVMe disk (instead of SCSI) and starting the VM in order to format it as NTFS with a Windows 10 ISO, powering it off and then attempting to mount that. So it's not just pre-existing disks, it's also brand new ones that have just been created and formatted with 16.2.2 ~ However if I then format the same disk as FAT32 it mounts, even as writable, just fine using recent versions.

I originally noticed this while using Windows 10 1809 but have since switched to 21H2 for both my host and test machines and the issue remains even after trying a virgin install of Windows in a VM and installing the latest VMware Workstation build there so either this will be really easy to reproduce or may be related to something else I haven't thought of yet.

I have isolated the driver:"vstor2-mntapi20-shared" as the culprit even though it is (amusingly due to its name) located at

"C:\Windows\SysWOW64\drivers\vstor2-x64.sys"

By manually stopping it and then reverting to the version shipped in 16.1.2, I can once again mount an old, or even a newly formatted, NTFS drive as writable. So I have my workaround for now but a proper fix would be ideal moving forward! 😃

[adpriest]

This is STILL a problem, and it's incredulous that 16.2.x has been so fundamentally broke through so many releases. This should have been fixed by now. 16.1.2 was the last working version for a number of issues, but particularly this one. It's STILL broke in 16.2.2.

[continuum]

If you can - stay away from the vstor driver - its toxic. See https://www.signal-labs.com/blog/vmware-driver-0day-reversing

I would recommend to switch back to "last known aceptable" Workstation : 16.1.2
Other than that I would recommend to use  standard industry procedures to share files between host and VM like cifs, nfs, scp ...


Ulli

[btmp]

Thanks for the link, I hadn't come across that before. Sadly after reading over it and looking into other VMware Workstation drivers installed  by default it appears most of them have the same security permissions set to allow "Everyone" read and write meaning that if the vstor driver is toxic so are the others. Looking more and more like I'm switching over to Hyper-V =(

[RDPetruska]

It's not just NTFS formatted disks.  I could no longer keep a DOS FAT disk mounted with 16.2.x -- it would mount and display in Explorer, but when trying to write anything to it, it would die.  Had to revert to 16.1.2, then disk mounting/reading/writing works just fine.

[RDPetruska]

Tried using 16.2.3 today... Same result.  Can mount the DOS disk, and browse it.  But attempting to copy files to/from it results in error message about drive not being available.  Reverted back to 16.1.2 yet again.

[btmp]

I've moved on and am now using Hyper-V but I used Workstation for many years previously and somehow 'expected' that once I moved on they would suddenly fix everything! (That's how my luck tends to go...)

Thanks for the update on the more recent revision, it saves me the effort of re-testing that much myself!

I'm obviously still rooting for VMWare to correct Workstation in this (and other aspects) but it's been well over a year since 15.5.x was a near perfect version (while IMO 16.x versions no longer 'just work') and they are no longer producing any 15.x [security update] versions so IMO we are currently stuck between 'acceptable security' or 'annoying usability' or 'unacceptable instability'..Sorry none of those choices worked for us in the long term!