Mount shared folder in Tumbleweed VM using OPEN-VM-TOOLS with VMware Player 7.1.2

I’ve created a Tumbleweed VM on a Windows 7 host using VMware Player 7.1.2 as part of the installation the OPEN-VM-TOOLS package was installed.

Can someone point me to instructions which show how to setup Shared Folders in Tumbleweed (build date is 07-02-2015) ?

I had tried to do this unsuccessfully so then i uninstalled OPEN-VM-TOOLS using YAST and then downloaded VMWARE TOOLS.

After installing VMWARE TOOLS, i could not autoresize the window which the virtual machine ran it so i ran the uninstall script for VMWARE TOOLS.

I’ve now reinstalled OPEN-VM-TOOLS using YAST and i can resize the VM window, but i’ve not been able to get shared folders to work.

Any assistance would be appreciated. I can delete the Tumbleweed VM and reinstall if needed.

             Thanks,

              Chuck H.

Although I use the closed source from VMware,
The procedure shouldn’t be any different using open vm tools from what I’ve read…

  • Make sure the Guest settings “shared folders” is enabled.
  • Configure the shared folder path for the Host
  • Boot up your Guest, your open vm tools should be installed.
  • Inspect your /mnt/hgfs/ location. That folder should have already been created and if your shared folders is working, you should already see that folder populated with the shared folder. If it’s not already populated, then you will need to mount the shared folder using the following syntax (The folder name is whatever you call it and is the italicized “ShareFolderName” in the following examples)
mount -t vmhgfs .host:/*ShareFolderName* /mnt/hgfs

You can also automount the share in your fstab as follows

.host:/*SharefolderName* /mnt/hgfs vmhgfs defaults 0 0

There is a tool in the open vm tools called “vmware-hgfsmounter” which I have not used that is supposed to do the same as the above command that mounts the folder manually.

HTH,
TSU

here are the commands that i tried to do the mount

spcwh2@linux-xmhl:~> su
Password: 
linux-xmhl:/home/spcwh2 # vmware-hgfsclient
D
F
VM-Shared-Folder
linux-xmhl:/home/spcwh2 # mount -t vmhgfs .host:/F /mnt/hgfs
Error: cannot mount filesystem: No such device
linux-xmhl:/home/spcwh2 # vmtoolsd -v
VMware Tools daemon, version 9.10.0.43888 (build-2476743)
linux-xmhl:/home/spcwh2 # uname -a
Linux linux-xmhl 4.0.5-3-desktop #1 SMP PREEMPT Thu Jun 18 15:11:06 UTC 2015 (56152db) x86_64 x86_64 x86_64 GNU/Linux

am i doing something wrong, i think that what i did matches your instructions.

<sigh>

When I started looking at this closely, I discovered that all updated openSUSE 13.2 now installs open-vm-tools instead of the community version of vmware tools which has been used “since forever.” Don’t know when this changed, and it’s significant because…

The next thing I discovered is that as you described, there’s something wrong with the Shared Folder feature. My initial reaction is that this may have something to do with matching Guest Tools with the version of VMware installed, it’s something I have observed and have carefully made sure was addressed in every machine I support despite wolfi’s strong opinion my concern isn’t a real issue(I’ve found this issue applies to both VMware and VBox). But, I don’t know that this open-vm-tools is versioned and sync-d with any VMware version release.

After discovering that Virtual Folders isn’t working with open-vm-tools, I next proceeded to try to remove it and replace with proprietary VMware tools, but then I found I’m stymied there as well (unless and until I find something new). I suspect somehow that open-vm-tools is not a drop-in replacement for the standard VMware Tools api and modifications were made to openSUSE to accomodate the new open-vmware-tools (which would be a very bad decision).

I will be looking at this further to verify what I’m looking at and attempt to do some troubleshooting, but for now I believe

  • That once you have open-vm-tools installed, you are stuck. You cannot switch to any other version of Tools (the older legacy community Tools or proprietary Tools distributed by VMware)
  • Virtual Folders does not work. I suspect again although superficially at the moment that this might be related to manually patching/altering functionality instead of writing to the standard API that VMware uses.
  • My current recommended try (unverified) is to
  1. First, only install from older source, do not install using online sources
  2. install either the older vmware community tools if they can be found or the proprietary Guest tools <before> executing a “zypper up” – Once you execute a zypper up or allow Apper to update your system, you may have no recourse except to pave and re-install.

IMO this is a very serious issue that needs to be reported if the two of us aren’t just looking at co-incidental anomalies.

TSU

The bugzilla says that the shared folders issue can be addressed with a workaround posted at the open-vm-tools site

The reported bug
https://bugzilla.opensuse.org/show_bug.cgi?id=904373

The referenced page which contains the workaround
https://github.com/rasa/vmware-tools-patches

Is exclusive of the other issues I ran into but could address the topic of this thread.

TSU

For anyone looking into this,
The following official VMware reference regarding use of open-vm-tools
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2073803

It looks like among various other “best practices” described, open-vm-tools should not be removed. So, it looks like it’s not possible to use proprietary tools in any distro that automatically installs open-vm-tools anymore.

So, any changes to the plumbing that connects Guest tools and the distro seem to be fully authorized due to this new policy forcing the use <only> of open-vm-tools.

So, now I’d think that if openSUSE can’t push patches nearly in realtime as they’re created on the github site, a script should be created that installs patches with “one click.”
Right now, it’s a bit involved to manually set up the pre-requisites and re-compile the kernel with patches.

Since the VMware KB is only a few months old, although open-vm-tools has been in Factory for awhile, I’m guessing this started being pushed through the standard repos is only a very recent development.

TSU

For anyone who wants to patch and re-install their Guest tools,

Supported openSUSE and VMware apps
All GuestOS versions openSUSE 11.x and later should be supported
All HostOS versions of VMware Player, Woirkstation and Fusion
Requires an Internet connection.

The quick and easy way (Limited testing, post here if you run into a problem)
In the Guest,
Select a location of choice where you will do your build. I recommend the User’s Downloads folder, but it can really be anywhere on the system.

I’ll create a downloadable script with more automation later, but for now you can just create a script in your chosen location and copy the following into that script, make it executable and execute. You can stick around long enough to verify that the zypper command has executed, checking for and installing prerequisites. After that, go and get a cup of coffee and come back in about 15 minutes.


zypper in git make gcc kernel-devel wget && \
git clone https://github.com/rasa/vmware-tools-patches.git && \
cd vmware-tools-patches && \
./download-tools.sh && \
./untar-and-patch.sh && \
./compile.sh

Your Shared Folders and anything else should work now(I’ve verified).

Note that you may need to reboot to regain full Tools functionality.
On one of my test machines, auto display re-sizing did not work immediately.

For anyone who has already done this patching but wants to re-install, possibly to get additional new patches, just delete the extracted folder “vmware-tools-patches” and run this script again.

TSU

TSU a couple of questions about this.

  1. Do we need to remove the OPEN-VM-TOOLS package via YAST ?

  2. Do we use the VMWARE-TOOLS which is available in VMWARE PLAYER ?

  3. Does the automatic resizing of the guest when resizing the PLAYER window always work successfully ? (you mentioned that it did not wrok at first, this is a deal breaker for me if it doesn’t work).

I added the following lines to my /ect/fstab file to provide the similar functionality via a network share. So I’m a bit reluctant to try the patch if it impacts the autoresizing of the VM Player window.

//i5-3570k/D /windows/win-d  cifs auto,gid=users,file_mode=0755,dir_mode=0755,iocharset=iso8859-15,credentials=/etc/winpassword 0 0
//i5-3570k/F /windows/win-f  cifs auto,gid=users,file_mode=0755,dir_mode=0755,iocharset=iso8859-15,credentials=/etc/winpassword 0 0
//i5-3570k/vm-shared-folder /windows/VM-Shared-Folder  cifs auto,gid=users,file_mode=0777,dir_mode=0777,iocharset=iso8859-15,credentials=/etc/winpassword 0 0
  1. No, you should never remove an open-vm-tools once it has been installed.
  2. According to the open-vm-tools documentation, you can specify a Tools version which is what you would be doing by installing a version that came with your app (VMware Player for instance) which would be assured of working with that version of the app, but you can also install the latest version which is what my script does by not specifying a version (My script downloads all versions from VMware). Apparently the latest released Tools version should work as a replacement for all VMware apps where open-vm-tools has already been installed by the distro, so my script should always work.
  3. Re-sizing the window is one way to test whether the patching worked and is running properly. The other is whether the hgfs directory was automatically created and exists in /mnt (eg the following command)
ls /mnt/

If either of both of these don’t work immediately (they should) then you should reboot the Guest and then both tests should be successful.

I’d generally recommend not making the fstab entry until you’ve verified manually mounting the shared folder works. If there is a problem, manual mounts are a lot easier to troubleshoot.

BTW - Once patched, open-vm-tools like many other things in openSUSE works like a champ. I’ve also done the same to Ubuntu(yes, this same issue exists there today) and there are a number of little imperfections you won’t see in an openSUSE.

TSU

Hi TSU,

now that we’re on the 4.1 kernel, do know if the patches will still work on the 4.1 kernel ?

Shouldn’t be an issue,
Particularly for something like TW which might introduce kernels more frequently, the script I created ensures that your kernel sources and headers are updated and consistent with the installed kernel. You could even change to another flavor kernel and running my script should pick up the changes(keep the script handy. If some Guest functionality stops working, it’s probably because of a change in your machine and the script should fix every time).

TSU

The latest open-vm-tools from the repos do not work though as they expect you to have 4.0.5.


tumble-esxi:~/vmware-tools-distrib # zypper in open-vm-tools
Loading repository data...
Reading installed packages...
Resolving package dependencies...


Problem: nothing provides kernel-uname-r = 4.0.5-3-default needed by vmware-guest-kmp-default-9.10.0_k4.0.5_3-2.2.x86_64
 Solution 1: do not install open-vm-tools-9.10.0-2.2.x86_64
 Solution 2: break vmware-guest-kmp-default-9.10.0_k4.0.5_3-2.2.x86_64 by ignoring some of its dependencies

I didn’t bother recompiling them and instead went for the official VMware tools route.

Are you saying that some version of open-vm-tools isn’t already installed?
In any case, running my script should build open-vm-tools from scratch using the latest released VMware Tools from VMware and replace whatever previously existed.

Also, the error you’re getting is odd. The step to download and specify the “kernel (uname -r)” is done only when compiling in the apt management system (debian). The prerequisites to compile to yum/openSUSE are different. You can inspect different requirements running my updated script (still testing) which can be applied to all known major distros

(Verified working for openSUSE, Ubuntu, Mint but should also work for Fedora/RHEL, Debian, etc)

Interesting you say you were able to install the proprietary Tools, that failed for me on Workstation. I’d guess that is because somehow your openSUSE install wasn’t created in a VMware environment which would have installed open-vm-tools. Once open-vm-tools has been installed, I’ve found you can’t switch to proprietary tools.

TSU

No no, I wasn’t talking about your script - sorry :slight_smile: I should’ve said it there.

I was referring to the fact that the Tumbleweed you currently get from the repos ships with an open-vm-tools… that doesn’t actually work because it expects the the kernel to be 4.0.5.

Although I haven’t tested,
Running my script even in TW should fix whatever problem might exist because it ensures the prerequisites including kernel headers for the installed kernel are present, downloads the latest released Tools from VMware and re-compiles the whole thing replacing whatever might have been there before.

I am curious if you think you were able to install proprietary tools though, because at least in standard 13.2, when I uninstalled open-vm-tools, it wasn’t sufficient to enable proprietary tools to be installed. There were a number of errors, mostly non-critical but a few critical which led me to believe (and partially supported by reading documentation) that substantial changes were made to how Tools interfaces with the OS. In fact, it can even be said that the way open-vm-tools builds using Tools as a source that open-vm-tools is a kind of wrapper because Tools no longer can be installed by itself.

TSY

vSphere reports them as functional so I’m guessing VMware has fixed something, I did have to fix something for them to compile but I’m on the road atm. so I can’t check on what I did.

After going through a number of my Guests,
It looks like if you didn’t run “zypper up” after approx July 10 (more or less), then you’d still have the old architecture and can still install Proprietary Tools.

But, if you ran “zypper up” on these Guests any time after about July 10, then open-vm-tools would be installed replacing whatever you had installed before (Community or Proprietary) and once that has happened, there is no going back. From then on, you have to use open-vm-tools going forward and if you want shared folders you have to patch.

TSU

question, i did have open-vm-tools installed on my Tumbleweed vm, will these patches work to allow the shared folders to work correctly ?

I did try to run all the steps to install the patches however, the shared folders are NOT present in mnt\hgfs folder

Yeah,
It seems that Shared Folders is broken in TW.
Just tried everything I can think of, I was able to compile without error (even the shared folders module compiled without error) but that one feature doesn’t work. Looks like other features are working properly.

The only solution I can think to try would be to roll back the TW install at least to July 1 or earlier, then try to install VMware proprietary drivers (which might be possible if open-vm-tools has never been installed on the system).

If anyone wants to try patching a TW install, I found 2 unusual requirements besides those for ordinary openSUSE, you must have at least 6.5GB free space (this means can’t build on very small disks, esp with BTRFS snapshots stored) and you must install support for ifconfig

zypper in net-tools-deprecated

It may be worth creating a bug at https://bugzilla.opensuse.org, Maybe someone who understands what is different about TW and the new open-vm-tools API can figure this thing out.

TSU

I have recently installed TW as guest on workstation under windows 10, and couldn’t get the shared folders to work with open-vm-tools for anything until I read this thread. Initially I was concerned but it did indeed work like a charm. I cut and pasted the above script into a script I called shared.sh and performed a chmod 755 on it and subsequently executed it and after 20 minutes of downloading [crappy uverse 18mbps dsl] it worked like a charm. Thank you very much TSU.