Clipboard operations (copy/paste) often stop working on VMWare Workstation

I have a dual-screen set-up with a Windows host and a Linux virtual machine.

Windows Host: Windows 7 x64, VMware Workstation (8.0.5, most recent)
Linux VM: CentOS 6.4 x64 (most recent) + VMware Tools (most recent)

The shared clipboard feature is of great importance to me. I often copy commands from the Windows host into the Linux VM, but clipboard sharing often stops working.

A reboot of the guest does not solve the issue. A reboot of the Windows host machine does solve the issue, although it's only a temporary measure. The issue often comes back within 20-30 minutes after reboot.

9

18 Answers

I once spent a few hours rebooting, reinstalling VMtools, etc., while the fix was really suspending and restarting VMware itself.

12

I have the same issue but Host is Windows, guest is Windows. I force kill vmtools and rerun them and that has always made cut/paste continue to work.

taskkill /F /IM vmtoolsd.exe
"C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr

Not sure what the command would be on centos to kill client tools.

6

This is what worked for me:

Attempt to close VMWare Workstation. You will be prompted with some options on what to do with your running guests (if any are currently running): Suspend, Power Off, Run in Background, Cancel.

Select Run in Background. Reopen VMWare Workstation.

5

If your guest is Unix-based, you can run this.

It grabs the pid of vmtoolsd, kills it, and restarts it. That will repair the copy/paste functionality:

#!/bin/bash
processString=$(ps -ef | grep '[0-9][0-9]:[0-9][0-9]:[0-9][0-9] /usr/bin/vmtoolsd -n vmusr') # get process info for vmtoolsd
tokens=( $processString ) # tokenize
kill "${tokens[1]}" # grab pid and kill it
/usr/bin/vmtoolsd -n vmusr & > /dev/null 2>&1 # restart vmtoolsd

Optionally save it as a script and put the script in your $PATH so you can run it more easily. You do not need to reboot your VM or restart VMWare.

4

I just restart the VMware services on the host when it happens.

Try avoiding canceling the copy and paste operation. Also only perform one copy and paste operation at a time.

4

If running Windows on Windows, try using the VM over RDP. Should be more stable this way. I know this has no relevance to the original question, but some people may find it helpful, because this topic has poor coverage on the internet, with no good solution.

2

I had the same issues but with open-vm-tools (Ubuntu 14 guest, Win10 Host)

I solved it by simply restarting VMware Workstation (as mentioned previously)

Everything took just 2 sec.

What I didn't know: Your running Virtual Machine is not suspended nor stopped.

Just click File -> Exit (or the X) and choose "Run in Background" Then start VMware Workstation again, et voilĂ , copy&past works again!

0

It looks like there are a number of possibilities to cause this copy/paste dropout failure between hosts, so I'll add my fix here. (And yeah, I am aware I'm using different VMWare, different host OS, and different guest OS compared to those specified in this question, but it really seems to be a vmware tools thing, so hopefully it will help some people who land on this page like I did.) Of course you have to have VMWare Tools installed -- update them first probably -- and the guest isolation options must allow copy/paste as others have mentioned.

First my setup:

  • HOST - MacOS 10.13.4
  • GUESTS - Windows of various versions.
  • Fusion - 8.5.10

(Though, this clipboard working and then suddenly not working has been happening in previous versions of MacOS and previous updates to Fusion 8.)

My Fix: Stop the vmware tools service "VMTools," exit/kill the vmware tools tray app, restart the service, restart the vmware tools tray app.

Commands to run in Windows guests, as Administrator: (tested in powershell and CMD)

net.exe stop vmtools
taskkill /F /IM vmtoolsd.exe
net.exe start vmtools
start "" "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" "-n" "vmusr"

This is working for me... for now. Of course your mileage may vary, and if you have comments on my answer please let me know. I know the "vmtoolsd.exe" used to be called something else in previous versions. Maybe its startup parameters are the same, maybe not.

I use this in a batch file with a 1-second delay between each line. There are various ways to insert delays, and Rob van der Woude has a rather darn comprehensive list of those ways.

The same general methods may work in other guest OSes, but I don't have the details of how to do that.

I hope this helps someone!

Had a similar problem with Workstation 10 (W7 host, 2008R2 guest), copying from guest to host didn't work, copying from host to guest did.

Restarting vmtoolsd.exe -n vmusr on guest and vmware-tray.exe on host solved it.

1

The most general and thus the best way to make copy/paste to work in VMware (version 14 atleast) running Linux/Ubuntu Desktop guests is to add the below bash-script to your $HOME/.profile:

# VMware: make copy/paste and drag/drop to work in Ubuntu Desktop guest
# Note: this should run automatically with xdg/desktop entry, but it doesn't :(
[[ -x /usr/bin/vmware-user-suid-wrapper ]] && /usr/bin/vmware-user-suid-wrapper

After you add that in your Linux/Ubuntu $HOME folder, just log out and restart Ubuntu/Linux-guest OS, log in.. and the copy paste is working!!

The script /usr/bin/vmware-user-suid-wrapperstarts the user-space daemon of vmtoolsd and it can also be run manually

You can also check that two (2) vmtoolsd daemons should be now running in your system. Both are needed and the one with args: -n vmusr .. is the one that makes copy-paste and drag-and-drop to work. Running `ps aux | grep -v vmtoolsd | grep vmtoolsd' will show this:guru@visuxmono:~$ ps aux | grep -v grep | grep vmtoolsd root 762 10228 Ssl 21:20 0:03 /usr/bin/vmtoolsd guru 3053 34092 S 21:21 0:03 /usr/bin/vmtoolsd -n vmusr --blockFd 3

2

It turned out open-vm-tools-desktop was not installed automatically together with open-vm-tools in my virtual Ubuntu 20.10.

sudo apt install open-vm-tools-desktop

fixed the issue immediately.

The clipboard sharing feature requires that VMware Tools be installed in the your virtual machine. It also enables you to drag and drop between virtual machines and your host OS.

I would say double check to see if VMWare tools are installed. If they are, maybe remove and re-install them. If that doesn't work, you can try updating the VMware workstation. VMWare 9.0 is now available!

1

Had the same issue with version 10.0.

First make sure Guest isolation is deactivated: VM Settings > Options > Guest Isolation both are enabled.

Try to copy and paste from external HD or removable drives, not from your system partition.

My setup: VM stored on external HD. Copy paste from internal HD (C:) doesn't work, copy and paste from external HD (E:) will work. I assume C&P is deactivated for the local system partition.

Experienced it right now on Windows 7 64bit as Host and Guest, VMWare Workstation 9. The solution on my side: The service VMware Workstation Server was set to start manually on the host. After starting this service (and configuring it to start automatically) copy and paste worked normally again between host and guest.

In my case simply restarting the VMware tools service in guest resolved this issue (drag and drop of files is working but copying of text via buffer between host and guest does not).

I generally access a Windows guest running in VMWare on another Windows box from my own Windows workstation. I remote in using standard Windows "Remote Desktop Connection".

In this configuration having the Remote Desktop window NOT fullscreen generally enables the clipboard to work. When it is fullscreen and I switch back and forth often that is when the clipboard will fail.

Note - the VMWare window on the server box CAN be fullscreen, that doesn't seem to matter.

it's wrong in the first place to use the VMWare Workstation/Player. You just create the VMs and leave them running in the background.

And use something terminal manager like MobaXTerm, SuperPutty, Kitty This way you get much more functionality and better management.

1

The first thing you should do is determine which way is broken because they are controlled separately. If host-to-guest clipboard doesn't work but guest-to-host does then the restart vmware.exe trick in the other answers will work. However, if it happens continually then you likely have a problem in an app other than vmware.exe.

Many years ago I wrote a program to identify Windows hooks. One hook I used to find that often causes trouble with other applications is the WH_CBT hook. As it happens, today I was using VMware Workstation and the host-to-guest clipboard just wouldn't stay working more than a few seconds after run-in-background and restart. I used my program to scan the host desktop for hooks and killed all programs that used WH_CBT hooks. After that host-to-guest started working again. Through the process of elimination I've found a 100% reproducible disconnect on host-to-guest by opening Windows Firewall on the host (wf.msc which runs from mmc.exe). It sets a WH_CBT hook:

----------------------------------------------------------------------------[b]
[Found] [HOOK 0x5AD1127B @ 0xFFFFF900C0940A90] [11:26:13 PM 3/3/2022]
Id: WH_CBT
Desktop: Default
Owner/Origin/Target: mmc.exe (PID 22120, TID 42528 @ 0xFFFFF900C1E87C10)
----------------------------------------------------------------------------[e]

My program is called GetHooks. I never officially released a 64-bit version because I couldn't get it working with Windows 10 x64, but it can be built for 64-bit from source for older versions of Windows.

devenv.exe (Visual Studio) is another program that sets CBT hooks but it usually does them properly so unless your Visual Studio hangs or something it is probably not the cause.

Unfortunately lots of programs set WH_CBT and not all of them do it properly, even Microsoft. The best advice I can give you for Windows 10 is if all of a sudden host-to-guest stops working repeatedly it may be some other program that you have open that set a hook that is actually the cause and NOT VMware. What you observe with VMware may actually be a symptom of more serious problem of a lazy hook in a different unrelated program.

You Might Also Like