Serious bug in Shared Folders feature in VmWare Workstation 8.x

[DmitryBond]

Hi.

I see - there is a serious bug in that feature!

In particular scenario is following:

• Enable Shared Folders feature for VM (let say = "D:\share" on host PC will be visible as "Z:\HostShare" on VM)
  (here you can suspend/resume VM couple of times)
• On VM, using a shell script copy all *.h, *.c* files from "Z:\HostShare\sandbox\modules\core\myApp1\source" to "D:\sandbox\modules\core\myApp1\source"
  (here you can suspend/resume VM couple of times and then repeat the same copy-operation)
• On host PC - open any of *.h, *.c* files which were copied on VM - edit it and try to save, Windows on host PC will report "file access error" - file is in-use and cannot be overwritten (or such)

Solution:

• go to VM, open VM Settings, disable Shared Folders feature, click [OK], then enable Shared Folders feature back

As I can see this bug is exists in VmWare Workstation for quite a long time (more than 3 years).

Could you pleas fix it, finally?

The idea is - Shared Folders feature MUST NOT EXCLUSIVELY LOCK FILES which were accessed from VM. Especially when these files were closed/released on VM.

Thank you in advance.

Dmitry.

[wila]

Hello,

I don't think that fixes on this will be made to Workstation 8 as the product has been retired.

The lowest version of VMware Workstation that is still supported is Workstation 9.

See also: http://www.vmware.com/files/pdf/support/Product-Lifecycle-Matrix.pdf

Having said that, there is a number of fixes in the Host Guest File Sharing file system in the last 2 years.

This might include your problem here. The only way to find out is by testing I suppose unless somebody here recognizes your problem and knows if it was addressed or not. You can download a 30 day -unlimited- Workstation version to try and test if it helps, before spending money on it.

Another thing you might consider if the problem actually lies elsewhere, as yes unmounting a filesystem will release locks, there's little doubt on that.

It doesn't however mean that the filesystem itself maintains the locks (it might though)

For example:

Do you use an antivirus product? If so, did you exclude the host file system?

Hope this helps,

--

Wil

[AlanaA]

I encountered a similar issue this week with Workstation 10.0.3 on a 64-bit Windows 7 host and a 64-bit Windows 7 guest. I normally use the built-in SMB/CIFS network sharing capabilities of host and guest OS's due to performance and other quirky issues with VMware's Shared Folder feature but I just needed to share a single file and opted to use Workstation's Shared Folders feature instead. I shared a folder from the host to the guest. I opened a text file in the shared folder, modified, saved and closed the file. While the guest was still powered on but the shared file wasn't opened by any guest application, I then opened the shared text file from the host side, modified it but was unable to save it. I got the same file access error. Disabling the folder share from the guest's settings allowed me to save the file on the host side.

So, I may have encountered the same issue as you. I ended up using Windows 7's built-in SMB/CIFS support since the Shared Folders feature wasn't saving me the few clicks I had hoped.

[DmitryBond]

I also confirm - this bug is stille exists in VmWare Workstation 10.0.3! 😞

Do you know if there a way to bring this to the attention of WmWare Workstation development team?

[dxiv]

Running v10.0.3 on Win7 x64 here, and I don't see the bug with either Win7 x64 or XP guests. Simply copying a file from the guest to a shared folder and/or modifying it doesn't leave the file locked, and the host can edit/resave or delete it afterwards just fine, while the guest is still running.

Wil asked the question earlier in this thread whether any antivirus was present. Or maybe there is some configuration difference which could trigger the "locking" behavior in certain cases.

Sysinternals' handle.exe can lookup the owner of an open file handle. Might be worth checking what both guest and host think is the process that keeps the file opened.

[DmitryBond]

Hi.

Antivirus (ESET NOD32 Antivirus 7.0.302.26) is running only on host PC (Windows 7 Ultimate x64).

There is no running antivirus on VM (Windows Server 2003).

Here is what reported by handle.exe tool (from SysInternals):

------------------------------------------------------------------------------

vmware-vmx.exe pid: 12524 DOM1\dbondare

   10: File  (RW-)   C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_08e61857a83bc251

   D0: File  (R-D)   C:\Windows\System32\en-US\KernelBase.dll.mui

   DC: File  (RW-)   C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_08e61857a83bc251

   E0: File  (RW-)   C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_08e61857a83bc251

  10C: File  (RW-)   D:\VM\vmware\BtoDevVm\vmware.log

  1A4: File  (RW-)   D:\VM\vmware\BtoDevVm

  1F8: File  (R-D)   D:\VM\vmware\BtoDevVm\BtoDevVm-d984f3d3.vmem

  2C4: File  (RW-)   D:\VM\vmware\BtoDevVm\BtoDevVm-s001.vmdk

[...]

  3B4: File  (R--)   D:\!sandbox\R63NS\modules\Core\plantcalendar\Applications\PlantCalendarEx\source\UPCal2DefaultConfig.pas

  3B8: File  (R--)   D:\!sandbox\R63NS\modules\Core\plantcalendar\Applications\PlantCalendarEx\source\ufrmPatEvent.pas

  3F4: File  (R--)   D:\!sandbox\R63NS\modules\Core\plantcalendar\Applications\PlantCalendarEx\source\ufrmCalendar.dfm

  57C: File  (RW-)   D:\VM\vmware\BtoDevVm\BtoDevVm.nvram

  6C0: File  (R--)   D:\!sandbox\R63NS\modules\Core\plantcalendar\Applications\PlantCalendarEx\source\ufrmCalendarView.dfm

[...]

Blue-marked files are the exactly the files I copied on VM using shell script commands. As you can see the process who owns the lock is vmware-vmx.exe.

Note: the locked files are the program source code in sandbox, I have a script on VM which runs shell commands like this: "copy *.pas .\", "copy *.dfm .\", "copy *.dpr .\".

As result of these shell commands execution VM ware lock some of copied files on host PC.

In an output of handle.exe I can see that .pas/.dfm files are not locked by any other processes.

Do you need more evidences of this bug?

I agree that this maybe somehow related to antivirus activity but as you can see - the locker process is VmWare, not the antivirus. So, most probably bug is exactly in VmWare.

Update: I just made a bit more tests and found that when antivirus is OFF it is locking files less frequently. So, from 10 copy operations it will lock only in 4-6 cases. With antivirus ON it locks files in 8-9 cases of 10. So, antivirus affects this a bit but seems it does not play in main role in files locking.

[wila]

Hi,

With some antivirus products "OFF" is not really off. Can't say much about NOD as I stopped using it a long time ago.

It is at least suspicious that it makes a difference in the behavior that you are seeing between "off" and "on".

When I saw your shared folder name the "!" character in the foldername "!sandbox" also raised a red flag with me.

Yes it is a perfectly acceptable character, but it might trigger the problem you are seeing somehow.

Can you test with a folder name that has only plain characters?

--

Wil

[DmitryBond]

Ok.

I renamed folder to "sandbox" (without "!"), then switched OFF and ON SharedFolders feature on VM. Then I tried the same test again.

I can see that nothing was changed. It is still locking that files:

vmware-vmx.exe pid: 12524 DOM1\dbondare

[...]

  6EC: File  (R--)   D:\sandbox\R63NS\modules\Core\plantcalendar\Applications\PlantCalendarEx\source\ufrmEvPeriod.dfm

  6F4: File  (R--)   D:\sandbox\R63NS\modules\Core\plantcalendar\Applications\PlantCalendarEx\source\ufrmTtMatrixSetter.dfm

  6F8: File  (R--)   D:\sandbox\R63NS\modules\Core\plantcalendar\Applications\PlantCalendarEx\source\ufrmSchedule.pas

  6FC: File  (R--)   D:\sandbox\R63NS\modules\Core\plantcalendar\Applications\PlantCalendarEx\source\ufrmCalendar.pas

[...]

Not sure about AV uninstalling to test it... that sounds a bit time-consuming (not sure if I could find more 1-2 hours for such tests).

Why not to admit - there is a bug and just submit it for fixing?

[wila]

Hello ,

It is good to know that the "!" character is not a parameter in the problem that you experience.

Not sure about AV uninstalling to test it... that sounds a bit time-consuming (not sure if I could find more 1-2 hours for such tests).

Why not to admit - there is a bug and just submit it for fixing?

I understand you're hesitant on uninstalling AV, it is however the only reliable way to completely rule out that antivirus is involved.

Antivirus products use pretty low level hooking methods as a way to monitor on-access and even when disabling the antivirus, there are still changes in comparison to a host without an antivirus installed.

Why not admit there is a bug you ask? Well I have nothing to admit as I am a user of VMware products, just like you, I do not work for VMware. I try to help out in the forums with replies and trying to isolate issues or answer if I am aware about a solution in my free time. If you have a current Support contract - like if you bought VMware 10 recently - then you can file a support request.

If you do not have a current support contract then there's still a chance that one of the developers from VMware who also attend the forums will pick up on it, but filing a support request is the only official way of making sure.

Another thing you could do is, especially as both guest and host are Windows, is using SMB file sharing. Network file shares are the industry standard way of sharing files between two windows machines.

Hope this helps,

--

Wil

[dxiv]

@DmitryBond, I was simply curious why you were seeing a bug that doesn't duplicate in my VMs. The difference appears to be NOD32, which answers the question for me.

Here is what reported by handle.exe tool

That's on the host side. Do the files appear as locked inside the guest, too?

Do you need more evidences of this bug?

*I* don't need any evidence whatsoever, but VMware support will certainly ask for some if you open a case with them.

[rich071]

Look at the link below about using a utility called unlocker. It works well to get around this problem. If it was an easy fix, they would have fixed a long time ago.

https://communities.vmware.com/message/1904322#1904322

I use shared folders a lot and this is the only issue I have ever had. Like I said, the unlocker solution works well to get around the issue.

Let us know if this helps.

Later,

[DmitryBond]

Unlocker is reported as "potentially unwanted" software by both - by antivirus and by Chrome browser.

I'm not sure if I want to install and use it. Also description of that application sounds like an OS-hack, it sounds like a workaround to existing problem, not as the solid/reliable solution.

So, using "unlocker" is not the solution.

I just checked if files also locked on VM side. As I can see files are not locked on VM side. So, lock exists only on host PC side.

Which is additional confirmation - this is bug excactly in VmWare service. So, OS on VM does not lock files but VmWare service still "think" that files need to be locked by some reason.

[rich071]

What you're seeing, from your anti-virus is a false positive. Unlocker has been around a very long time. It's probably being flagged because of the nature of the program. If you run the installer against the virustotal website, below, you will get 3 of 52 hits and if you run just the unlocker.exe, you will get 0 of 53 hits. Yes, installers can also cause false positives.

https://www.virustotal.com/en/

When you have the locked files problem, you may not see the locked files in the VM, but you can't delete them. What you will see is that the files are locked on the Host, by VMware. Usually, one or two locks. When you release the locks on the host, then the files can be deleted in the VM. You can release them, directly, by right clicking and selecting the file with Unlocker. I have a batch file in the toolbars on the Host, that  will auto unlock delete them, depending on the project. Run unlocker.exe /? at a command prompt to see all the options available.

This is a workaround to the problem. It is not a total fix. If you will search the forums for locked files or locked file handles, you will see lengthy discussions on this issue, from users and VMware employees. This is not something new. Like I said before, if it were an easy fix, they would've fixed it a long time ago. Depending on what you're doing, not everyone may have this issue.

It's up to you, if you want try it or not. It works here fine as a workaround.

Later,

[dxiv]

Running v10.0.3 on Win7 x64 here, and I don't see the bug with either Win7 x64 or XP guests.

Update: I've got a related, even simpler, failure case that duplicates the issue in both WS v10 and v11 preview - posted separately at https://communities.vmware.com/thread/495039.

[DmitryBond]

Update.

Today I have uninstalled antivirus S/W. Even standard Windows Defener is disabled and not started.

But as I can see - this problem is still take place in my work.

So, I make a conclusion - it is exactly VmWare is locking files in the exclusive mode and left them open, so I cannot work with these fines from host PC.

Which means - there is bug in VmWare Workstation in the SharedFolder feature implementation.

Hey, VmWare Team. Could you please fix it? Finally, please.

PS. I forgot to tell - now I'm using VmWare Workstation 11.0. So, looks like this is old bug which exists in all line of Workstation products.
Sorry, I cannot test it with 11.1 version because it is introducing another critical bug with VmNet8 virtual network adapter which preventing me from using 11.1.
Btw, I already written about that issue in 11.1 (Critical bug with Virtual Networks in latest VmWare update 11.1)

[rich071]

Here is a more detailed scenario that works for me.

I compile a program on the host, Test.exe, target folder is the shared folder in the VM, Drive Z:
I run and test the program in the VM
After exiting the program in the VM, Unlocker says there is No Locking Handle Found with Test.exe
On the Host, yes the file is locked with 2 occurance's of vmware-vmx.exe

I run a script on the Host that does the following
  Unlocker unlocks the file completely
  The file is then deleted
  The compiler compiles a new version of the Test.exe

Go back to the VM and I'm ready to test again.

One thing you have to realize, Workstation is a very complex program and will it ever be bug free, probably not. Have you looked at Virtual PC or Virtual Box as an alternative? They aren't bug free either.

Yes, there is an issue and I realize you're frustrated. If the workaround doesn't work for you, I suggest you open up a service call with Support and point to the threads that describes the problem.

With what I've seen, it appears that the Host/Workstation is not seeing that the program has ended in the VM and because of that the vmware-vmx.exe is keeping the files locked. On a real network share, the file would be locked as well. I going to assume, that the server now sees the file is not in use and will release the locks. Yes, it sounds simple but in reality, it must not be that simple in Workstation, otherwise I would assume that it would be fixed by now.

I realize that a lot of people have a lot of problems with shared folders. I use shared folders all the time and I can honestly say, this is my only issue after years of use.

Good Luck,

[DmitryBond]

Thank you for answer.

But...

1) It is not a matter of "frustration" at all! I just want to see a normal work process - I'm reporting a bug in product, bug is discussed and fixed.

2) Unlocker is not an option for me. I do not trust the executable which were written by unknown person with no open source code and when antiviruses (and webbrowsers also) are preporting it as "dangerous tool" and blocking it. For sure - I'm not going to use such tool!

3) Unfortunately, using a network share from VM is not an option for me because I'm workling with VPN (Cisco AnyConnect Secure Mobility Client) which is blocking all connections to my host PC when it is ON, so VmWare is not able to communicate with host PC as only by using via Shared Folders feature in such conditions.

Well, actually it is also possible to use FTP via NAT from VM to host PC but FTP is essentially less convenient and flexible as normal filesystem access.

[DmitryBond]

Ok. I understand.

Perhaps VmWare code bacame too complex, so nobody can maintain it anymore to fix that bug.

But could you please advice then - if there is a scripting possibilities to control VmWare service on host PC?

I mean - is it possible to run VbScript (or PowerShell script) to disable SharedFolders and then run script to enable SharedFolders back.

That would be good workaround for me.

[rich071]

The shared folder info is in the VMX file. You really don't want to edit that file while the VM is loaded or running. You will more and likely have further issues. From the GUI, you can enable or disable the Shared Folders while a VM is running. However, I have never tried to enable or disable the Shared Folders while a VM is running. I have added Shared Folders when the VM is running and that works well.

Personally, I have not tried this. The next time you have an issue, go into the Shared Folder settings and under the Host Path, uncheck the appropriate share. Click OK and then go back in and recheck it again and click OK. Post back with your results. If it does work, I'm not sure if can be easily be scripted or not. Maybe some of the VbScript or PowerShell guru's could give you an idea if can be done that way. Another scripting possibility would be using a macro type program or possibility AutoIt, both would need to be run from the Host naturally and both would work with the GUI. Also, if the above does work, it would be nice, if they added an Apply option, to go along with the Add, Remove, Properties, so you wouldn't be forced out of the VM settings and have to go back in immediately to reset the check box.

I know you don't trust my original workaround, but the file is safe, if you get it from the vendor's website, and the process works very well. That's all I got to say about that.

Good Luck,

[DmitryBond]

I perfectly know where and how to disable/enable SharedFolder feature manually.

Sorry, maybe I was not clear enough - my question was about different thing. In particular - how to disable/enable SharedFolder feature for running VM using some scripting (VbScript or PowerShell).

So, the idea to minimize number of clicks which I have to do to switch OFF/switch ON that feature. Because currently I have to make 12 clicks every time there appears a yet another deadly-locked file.

Because I'm editing source code on host PC and then making builds and tests on VM and that makes me clicking a lot to re-toggle SharedFolder feature because of file locks. 😞

Also could be an option - if source code of UnLocker tools will be publicly shared, so I can build it by myself locally - then I'm ok to use it as workaround (but I' ready to use my local build only of that tool!).