VMware Communities
Dr_Gary
Enthusiast
Enthusiast

Shared Folders Still Not Fixed in 2.0.2...

It appears that the one bug fix that I have been waiting patiently for has still not been addressed in release 2.0.2. Very disappointing.

The shared/mirrored folder SMB "lag"...at least with a Windows XP guest remains very apparent...I actually see no improvement at all. This causes Windows applications attempting to use a shared folder reference to experience write failures, etc. Totally unacceptable.

So...I am still unable to use this feature for my clients running Fusion...very, very disappointing...there were several threads on this board from VMWare folks that indicated this problem had been solved and was simply being QA'd for the next release. What happened?

Here is the Link:

http://communities.vmware.com/message/1130487#1130487

I guess Steve was misinformed...

Tags (1)
0 Kudos
72 Replies
WoodyZ
Immortal
Immortal

Up until Fusion 2.0.2 I have had nothing but problems with the VMware Shared Folders feature and this has been the same for over 5 years with Workstation as well however and although I'm not done testing yet I have to say that out of the box this feature has worked without any issues in Fusion 2.0.2 and have tried it under XP and Vista and have tried to make it act as it has in the past and for now it's behaving itself.

I'm still having startup and shutdown issues when I have all of Fusion features enabled so even though I'm no longer having issues with VMware Shared Folders feature the rest is going to be a deal breaker and it looks like I'll be sticking with Fusion 1.1.1 on my production system. Smiley Sad

At least for sharing there is a viable work-a-round by using SMB/CIFS however the time it takes for the Virtual Machine Library to become responsive and the abnormally long startup and shutdown times are deal breaker for me with using Fusion 2.x.

0 Kudos
Dr_Gary
Enthusiast
Enthusiast

That is interesting....

I still am experiencing intermittent slowdowns when simply browsing folders that are located on VMware shared folders. For no apparent reason...I will see a 5-10 second delay just trying to open a folder or sub-folder in Windows Explorer...this problem has caused many of my clients to experience data loss...for example, if they store their Quicken or QuickBooks data files or their Outlook PST on a shared folder....the application would sporadically experience delayed write failures...and clobber the data file.

This is really too bad...shared folders would be a great feature if it worked as designed.

0 Kudos
davidliu
Enthusiast
Enthusiast

Gary,

If you haven't done it already, can you update your VMware Tools in the VM and see if that helps? We shipped the shared folder performance fix in 2.0.2 and you need the newer Tools for that to work.

-David

0 Kudos
Dr_Gary
Enthusiast
Enthusiast

David

Yes...the tools have been updated....they show version 7.9.3, build 146107...

Gary

0 Kudos
davidliu
Enthusiast
Enthusiast

Thanks Gary. Did you also reboot after the Tools upgrade (stupid question I know .. just wanted to be sure)

-David

0 Kudos
WoodyZ
Immortal
Immortal

I still am experiencing intermittent slowdowns when simply browsing folders that are located on VMware shared folders. For no apparent reason...I will see a 5-10 second delay just trying to open a folder or sub-folder in Windows Explorer

That describes some of the behavior I've seen in the past and why I've always favored SMB/CIFS over using VMware Shared Folders.

...this problem has caused many of my clients to experience data loss...for example, if they store their Quicken or QuickBooks data files or their Outlook PST on a shared folder....the application would sporadically experience delayed write failures...and clobber the data file.

Yes and this of course is totally unacceptable!

This is really too bad...shared folders would be a great feature if it worked as designed.

I totally agree and from the first time the feature was introduced I wish it would have worked well. It has worked intermittently however in a production environment that is not good enough.

I have probably been one of the biggest thorns in the side of VMware over the years in regards to blasting them about this feature and I have given up and not because it now, at the present time, working for me in Fusion 2.0.2 (and only Fusion 2.0.2) but because I'm forced to stick with Fusion 1.x because the aforementioned time issues.

The irony here is I didn't have any problems with Fusion 1.x and have been very happy with it's performance but not with its lack of some features when compared to VMware Workstation and Parallels Desktop however for me, in general, Fusion 2.x has just been a big disappointment from a overall performance perspective and I even clean build the Mac and a clean install of Fusion 2 and I expect to have the same level or greater of performance as with Fusion 1 and I do believe my issues are in the minority of the total number of users but that doesn't make me any happier.

The good news is I can make do with what I have and how it works just as I have with any and all other products along the way and would not want to work in this industry without what virtualization has to offer.

0 Kudos
Dr_Gary
Enthusiast
Enthusiast

David..

Yes...I did...in fact...after your questions..and just to be sure.. I:

Uninstalled the VMware tools

Rebooted

Installed the VMWare tools

Rebooted

The issue remains..

Thanks,

G

0 Kudos
Dr_Gary
Enthusiast
Enthusiast

David,

Something interesting....after digging through some old Fusion support threads...I did the following to my XP guest:

Uninstalled Avast Anti-Virus

Uninstalled VMware tools

Rebooted

Installed VMware tools

Rebooted

And now...I cannot recreate the "lag" symptom at all. I will continue testing...could there still be issues with Fusion and Avast AV?

Thanks,

Gary

0 Kudos
WoodyZ
Immortal
Immortal

I know there were some issue with Avast in the past however I too am running Avast and am not having the same issues as in the past. Fusion 2.0.2 with Avast works as the feature is supposed to but with or without Avast all previous versions of Fusion I've had issue with VMware Shared Folders feature.

0 Kudos
davidliu
Enthusiast
Enthusiast

Interesting. We used to have shared folder issues when Avast 4.7 or 4.8 is running in the guest. The bug was fixed and tested with Avast 4.8. Can you let us know the version of Avast you were using?

-David

0 Kudos
WoodyZ
Immortal
Immortal

I'm using Windows XP Professional SP2 and SP3 with Avast! Professional 4.7.1098 in Fusion 2.0.2 and no problem with VMware Shared Folders feature. However in all previous version with or without Avast! I had extreme time lags when navigating VMware Shared Folders.

Startup and Shutdown times while improved are still too long compared to Fusion 1.x

0 Kudos
Dr_Gary
Enthusiast
Enthusiast

David,

I did have Avast 4.8 Home version installed.

Just an update...I have run my series of shared folder tests through 5 iterations...no issues at all.

I may just snapshot the current image...and re-load Avast to see if the symptom returns!!!!

Thanks,

Gary

0 Kudos
steve_goddard
VMware Employee
VMware Employee

Thanks for tracking down the Avast interop issue. Do you know which version of their AV you had installed?

I will try it here and investigate what the issue is. Was it the professional edition or the Home edition?

I tested our shared folders with a few anti-virus products last week at Microsoft and fixed a couple of issues I found there.

Avast were not there.

(I tested with a Microsoft's Forefront anti-virus and fixed an issue with that, McAfee AV, Symantec AV, Trend Micro AV.)

So we do take this feature seriously and am addressing as many of these type of issues as possible.

Please keep reporting issues wth the shared folders though if you do we can hopefully get them addressed.

Thanks. Steve
0 Kudos
RcktMan77
Contributor
Contributor

I have not been able to use the Shared Folders feature since upgrading to VMware Fusion 2.0. I use Vista Ultimate SP1 x64 installed on it's own Boot Camp drive for my virtual machine under OS X v. 10.5.6 on a Mac Pro. The problem persists in version 2.0.2 of VMware Fusion. My VMware tools have been updated, uninstalled, and reinstalled--they are at v. 7.9.3 build 146107. And yes, the guest operating system has been restarted several times. The problem is that for whatever reason
.host\Shared Folders cannot be discovered by Windows Explorer, and thus I am unable to view my selected folders which I have set to share. The only antivirus program I have installed is the McAfee package bundled with v. 2.0.2. Prior to VMware Fusion 2.0 I had no issues with the Shared Folders feature, and it worked as advertised flawlessly.

The only other problem with VMware Fusion that I have which also persists with v.2.0.2 is that there is no sound from the guest OS; although, sound works just fine in Mac OS X. I have tried resetting the PRAM as a suggested solution, but to no avail. I have seen someone with Windows XP SP3 share a solution in which they revert back to an older Creative Sound driver, but I do not have a Creative Sound Driver installed, but rather a VMware VMaudio driver. Prior to upgrading to VMware Fusion 2.0 the sound from both my guest OS and Mac OS X would play through my Harmon Kardon Soundsticks.

Any solutions forthcoming from the developers or VMware community would be much appreciated as fixes to these two problems have eluded me ever since upgrading to 2.0.

0 Kudos
steve_goddard
VMware Employee
VMware Employee

Thanks for the feedback.

Just to be clear, you have a boot camp partition with Vista Ultimate SP1 x64 and when you boot that as a VM you find that the shared folders does not work?

Sorry, but I have to ask, you have enabled sharing on the VM Settings menu option (tickbox Share Folders on your Mac)?

Also, assuming the above has been done, you have shares set up too, but it sounds like you are not getting that far?

Can you get me the registry settings for the registry setting values for:

HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order

Key: ProviderOrder

(It should be a string list.)

HKLM\SYSTEM\CurrentControlSet\Services\vmhgfs\

Key: Start

HKLM\SYSTEM\CurrentControlSet\Services\vmhgfs\networkprovider\

Key: ProviderPath

Can you verify what and if there are VMware files are in the following locations:

c:\WINDOWS\System32\vmhgfs*

c:\WINDOWS\SysWOW64\vmhgfs*

c:\WINDOWS\System32\Drivers\vmhgfs.sys

Thanks, these should help to verify at least if things looked to be installed okay.

Steve

Thanks. Steve
0 Kudos
steve_goddard
VMware Employee
VMware Employee

I installed Avast 4.8 home edition and I get the periodic stalls and from a quick trouble shoot it appears to occur every so often

on file opens with the FILE_EXECUTE access. No surprises I guess, given the product, that it decides to do work at this point.

However, what is puzzling is that, the delay only occurs on some files opened this way but not all. That maybe because it has

already decided it is safe and has cached information but who knows for sure.

Anyway, I will look into this further.

Furthermore, who knows why explorer uses the FILE_EXECUTE access permission since it is not going to actually execute the file

and it does this on all files, such as txt.

I will update again when I have more details.

Thanks.

Thanks. Steve
0 Kudos
WoodyZ
Immortal
Immortal

Can you get me the registry settings for the registry setting values for:

HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order

Key: ProviderOrder

(It should be a string list.)

HKLM\SYSTEM\CurrentControlSet\Services\vmhgfs\

Key: Start

HKLM\SYSTEM\CurrentControlSet\Services\vmhgfs\networkprovider\

Key: ProviderPath

It may be a lot easier to just copy and paste the following commands, as is, in a Command Prompt (Start > Run > cmd) and attach the vmhgfs.reg and files that are created on the Desktop.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\vmhgfs" "%USERPROFILE%\Desktop\vmhgfs.reg"

reg export "HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider" "%USERPROFILE%\Desktop\NetworkProvider.reg"

0 Kudos
steve_goddard
VMware Employee
VMware Employee

Yes, but you will need to run two reg commands as the other key is in a completely different place to the second two I listed.

Since, I only wanted three key values in two locations, it didn't seem worth exporting everything.

You can also right click on the HKLM\SYSTEM\CurrentControlSet\Services\vmhgfs key and select Export menu option from within regedt32 too.

Whatever works, but I will need HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order too.

Thanks.

Thanks. Steve
0 Kudos
RcktMan77
Contributor
Contributor

Steve,

Thank you for your timely response. Yes, you understand my setup and

sharing folder issue correctly: that I have a boot camp partition

(this is actually installed on it's own drive and does not reside on

the same physical disk as Mac OS X) with Vista Ultimate SP1 x64, and

booting into the VM the shared folders feature does not work with my

setup.

I have enabled "Share folders on your Mac" in the VM Sharing

settings. I have an alias/shortcut placed on my desktop in the VM

that has in the past (pre-VMware 2.0) opened Windows Explorer in my VM

to the directory of my shared folder. Clicking this shortcut now

provides the following Network Error message: Windows cannot access \

\.host\Shared Folders. I get the same error message if I try to map a

network drive in Windows Explorer using
.host\Shared Folders as the

server and share, respectively.

Can you get me the registry settings for the registry setting values

for:

HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order

Key: ProviderOrder

(It should be a string list.)

The ProviderOrder string is as follows:

vmhgfs,LanmanWorkstation,RDPNP,webclient

HKLM\SYSTEM\CurrentControlSet\Services\vmhgfs\

Key: Start

The Start string is as follows: 0x00000001 (1)

HKLM\SYSTEM\CurrentControlSet\Services\vmhgfs\networkprovider\

Key: ProviderPath

The ProviderPath string is as follows: System32\vmhgfs.dll

Can you verify what and if there are VMware files are in the

following locations:

c:\WINDOWS\System32\vmhgfs*

c:\WINDOWS\SysWOW64\vmhgfs*

c:\WINDOWS\System32\Drivers\vmhgfs.sys

The file vmhgfs.dll exists at C:\WINDOWS\System32\

The file fmhgfs.dll exists at C:\WINDOWS\SysWOW64\

The file vmhgfs.sys exists at C:\WINDOWS\System32\drivers\

I hope that answers to your satisfaction your inquiries. Feel free to

ask for clarification of anything if what I've provided isn't clear.

Thanks,

Zach Davis

0 Kudos