When running Fusion on a Mac, where does a shared folder appear if the Virtual OS is another version of Mac OS?

[QuakingBog]

I have a Mac running VMWare Fusion with "Snow Leopard Server" running as the guest, virtual OS.  The instructions say that I can specify a shared folder to shared between the main Mac OS, and the virtual Mac OS.

I've specified a shared folder, however, this folder is not showing up anywhere on the virtual server. Maybe I just have no idea where it should show up, so perhaps I'm not looking in the right place.

Does anyone know where I can find the shared folder within a version of Mac OS running virtually in VMWare Fusion?

(There are instructions about where to find a shared folder for Windows and Linux, but none for where it should appear for a virtual machine running Mac OS.) Thanks for any suggestions you can offer!

Best wishes,

Jeff

[WoodyZ · Accepted solution]

Using VMware Shared Folders requires VMware Tools be installed in the Guest OS, have you installed VMware Tools?

If yes make sure you have Shared Folders turned on in the Virtual Machine Settings and have added a shared folder.

If that has been done there should be a VMware Shared Folders alias on the Guest OSes Desktop.

If there no VMware Shared Folders alias on the Guest OSes Desktop then in a Terminal issue the following command to make sure both the System and User VMware Tools Daemon are running.

ps aux | grep vmware

The output should show information for two occurrences of vmware-tools-daemon.

kextstat | grep vmware

The output should list several extensions however the one associated with VMware Shared Folders is: com.vmware.kext.vmhgfs

Also look in /Volumes for VMware Shared Folders as that is the mount point in OS X for VMware Shared Folders.

Message was edited by: WoodyZ - Added command for checking kernel extension related to VMware Shared Folders.

[QuakingBog]

Thank you.  That worked perfectly!

[msohnius]

Hi, I have a related question, or indeed may have found a related bug:

I am running MacOSX "Snow Leopard Server" 10.6.8 as a Guest on a Mac Pro (late 2013) with "Yosemite" 10.10.2 as the host.  (The purpose is to have Rosetta to run older PowerPC applications.)  This setup appears not to be fully supported with all features, but more of that elsewhere. 

One of the issues is related to this thread:

Extended Attributes are not handles correctly for shared folders, presumably because the sharing mechanism uses a non-Apple protocol (such as SMB or NFS).  Here is an example:

If I take a screenshot in the Guest, then the resulting file has Extended Attributes.  Here they are, as seen on the Guest:

You can see the @-sign in the long listing, indicating that the screenshot has Extended Attributes and then the xattr(1) command shows what type they are.

Next, having used the Finder in the Guest to copy the file over to the Host's desktop, I look at it on the Host:

As you can see, the transferred file has no Extended Attributes, which are instead stored in a new "._" file; in other words, the transfer was made as if the protocol used was SMB or NFS, even though both ends are MacOS with HFS+ formatted disk drives.  HFS+, or the Host's Finder, does not recognise the ._* file as containing the Extended Attributes that should attached to the file.

Here is the problem in the opposite direction:  the listing for the VMware application on the Host shows Extended Attributes:

It has the Extended Attribute "quarantine" because it was downloaded from the Internet, using Safari.

But the long listing for the same file, as seen on the Guest, does not show Extended Attributes (nor are there any "._" files):

This, of course, creates loads of problems when using VMware's sharing.  Among them:

1.  The Guest does not see critical information (I noticed it, because some applications on the Host appeared as "UNIX executable" files on the Guest). 

2. The "._" files erroneously created on the Host will not get deleted if the main file is trashed.  As they are invisible, they will eventually pollute the whole filesystem, particularly as they may get re-attached to a different but identically named file if transferred to a non-Apple NAS backup system, which will then re-attach the left-over Attributes to the wrong file.

In my situation, this renders VMware's file sharing useless.

As a workaround, in my NAT-based network setup the Host and the Guest are neighbours on a LAN and I can use the Finder to set up an AFP (Apple File Protocol) mount of the Host's file systems on the Guest.  Then I see this:

All as it should be!  Similarly, copying a file from Guest to Host via an AFS-mount is OK.