Guests on Linux (19.3) hosts no longer have drag 'n drop or cut & paste support for files after upgrade to 15.5.5 or later, even with open-vm-tools 11.1 (or 11.0.6 for MS-Windows)

[NoelJB]

The title pretty much makes the point.

I am working around the problem by using shared folders, which do work between the guest and host.

When doing a d&d or c&p, the Error while copying dialog detail says 'Error when getting information for file "/Zsv1YQ/": No such file or directory'.

It appears to be one-way. I can move TO the guest, but not TO the host.

This is reproducible. I've restarted the systems, I've restarted (/etc/init.d/vmware restart) on the host, and restarted vmware-tools on the guest. Nothing has resolved the problem.

All of this was working fine prior to the upgrade (from 15.5.2).

vmtoolsd -v reports 10.3.21.249 (build-14772444), however I did uninstall that and installed the latest from the distro, which was 11.0.5, which failed, too, so I also build 11.1 from source, and that fails, too. So there does not appear to be any version for linux that works, not even the latest from source control.

VMware Tools for MS-Windows 11.0.5 failed with the same results., but upgrading MS-Windows to 11.0.6 fixed the problem there. [Update: It is failing for me now with MS-Windows as well, as documented in a further comment, below.]

Please advise. I'm available to test.

[oliverkurth]

Are you using Wayland? Unfortunately drag and drop does not work with Wayland.

You shouldn't use VMware Tools (the old tar installer, 10.3.20+) on Mint 19.3. It is recommended to use the open-vm-tools package that comes with the OS (currently 11.0.5). Mint is based on Ubuntu 18.04, and drag and drop is supported and works for Ubuntu 18.04. Note that you need to install both open-vm-tools and open-vm-tools-desktop (the former will be pulled as a dependency if you do apt install open-vm-tools-desktop).

We have a kb article that may help you if everything is set up correctly: https://kb.vmware.com/s/article/74671 .

[NoelJB]

You shouldn't use VMware Tools (the old tar installer, 10.3.20+) on Mint 19.3.
It is recommended to use the open-vm-tools package that comes with the OS
(currently 11.0.5)

Yes, as noted, I uninstalled VMware Tools and installed open-vm-tools from the distro. That also failed, as did 11.0.5 in an MS-Windows 10 guest. Only 11.0.6 in an MS-Windows guest is working, since I upgraded VMware Workstation from 15.5.2 to 15.5.5.

Are you using Wayland?

The running /usr/lib/xorg/Xorg process would imply not, I assume.

I read the knowledge base article. After running:

sudo systemctl status run-vmblock\x2dfuse.mount

I get the expected output, but it is /lib/systemd/ instead of /usr/lib/systemd/. And still no C&P or D&D with the host.

What diagnostics would you like for me to run, and provide results?

[slorg1]

Hi there,

May be related to #437

I am having the same issue since the update:
host is ubuntu 18.04, guests are ubuntu 18.04 and ubuntu 20.04

VM Player: 15.5.5 build-16285975
open-vm-tools & open-vm-tools-desktop from the ubuntu repo: 11.05.5-4

(I did the whole install, purge of the vm tools, reboots etc. alas... no luck fixing the issue)

• The drag and drop stopped working with the update (does not work guest -> host, it works host -> guest)
• Copy/paste of text still works.
• related in timing: I am having an audio issue (crackling in audio/video calls). I have not figured out why but it was not an issue before the update and is now an issue.

Thank you.

[oliverkurth]

I just tried to reproduce it - I installed a fresh Ubuntu 20.04, which comes with open-vm-tools 11.0.5-4. Drag/drop works both ways, unless I switch to Wayland where it works from host to the guest but not from the guest to the host (known issue), which is exactly what you describe.

What is the output of these command:
ps awx | grep vmtoolsd
mount | grep vmblock
ls -l /run/vmblock-fuse
?

To make sure you are not running Wayland, please also try these commands:

loginctl
then with the session id:
loginctl show-session <SESSION_ID> -p Type

[slorg1]

Hi,

Here are the commands output:

dev@virtual-machine:~
$ loginctl
SESSION  UID USER SEAT  TTY 
      2 1000 dev  seat0 tty2

1 sessions listed.

dev@virtual-machine:~
$ loginctl show-session 2 -p Type
Type=x11

dev@virtual-machine:~
$ ps awx | grep vmtoolsd
    739 ?        S<sl   0:25 /usr/bin/vmtoolsd
   2222 ?        Sl     0:23 /usr/bin/vmtoolsd -n vmusr --blockFd 3
  23498 pts/0    S+     0:00 grep --color=auto vmtoolsd

dev@virtual-machine:~
$ mount | grep vmblock
vmware-vmblock on /run/vmblock-fuse type fuse.vmware-vmblock (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other)

dev@virtual-machine:~
$ ls -l /run/vmblock-fuse
total 0
dr-xr-xr-x 3 root root 4096 Jun  8 14:36 blockdir
-rw------- 1 root root    0 Jun  8 14:36 dev
dr-xr-xr-x 3 root root 4096 Jun  8 14:36 notifydir

Thank you for helping me!

[NoelJB]

@oliverkurth,

This should be the output you want. I did a clean reboot first, verified that I can drag TO but not FROM the guest, and captured the info.

`$ ps auxwww | grep vmtoolsd
root 945 0.1 0.0 154552 7664 ? S<sl 18:02 0:00 /usr/bin/vmtoolsd
noel 1746 0.3 0.4 466784 37800 ? Sl 18:03 0:00 /usr/bin/vmtoolsd -n vmusr --blockFd 3
noel 2538 0.0 0.0 14424 1032 pts/0 S+ 18:05 0:00 grep --color=auto vmtoolsd

$ mount | grep vmblock
vmware-vmblock on /run/vmblock-fuse type fuse.vmware-vmblock (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other)

$ ls -l /run/vmblock-fuse/
total 0
dr-xr-xr-x 3 root root 4096 Jun 8 18:06 blockdir
-rw------- 1 root root 0 Jun 8 18:06 dev
dr-xr-xr-x 3 root root 4096 Jun 8 18:06 notifydir

$ loginctl
SESSION UID USER SEAT TTY
c1 1000 noel seat0
1 sessions listed.

$ loginctl show-session c1 -p Type
Type=x11

$ vmtoolsd --version
VMware Tools daemon, version 11.0.5.17716 (build-15389592)

$ uname -r
5.3.0-53-generic
`
I also made sure to give you the vmtoolsd version and the kernel version.

[NoelJB]

I am still seeing this issue. In fact, I am seeing it with MS-Windows 10 using VMware Tools for Windows 11.0.6. The host is Linux 19.3 with VMware Wotrkstation Pro 15.5.6.

The error message is the same. The host reports "Error while copying", and the detail is that it can't get information for file "/jDp5Rb/" followed by the filename.

The host vmware.log file shows:

020-07-17T10:23:45.617-04:00| vcpu-1| I005: HGFileCopyCreateSessionCB: Successfully created the session.
2020-07-17T10:23:45.620-04:00| vcpu-1| I005: Progress 0% (msg.HGFileCopy.ReadFile)
2020-07-17T10:23:45.652-04:00| vcpu-2| I005: Progress 1% (none)
...
2020-07-17T10:23:46.440-04:00| vcpu-2| I005: Progress 28% (msg.HGFileCopy.ReadFile)
...
2020-07-17T10:23:47.315-04:00| vcpu-2| I005: Progress 58% (msg.HGFileCopy.ReadFile)
...
2020-07-17T10:24:54.010-04:00| vcpu-1| I005: VMCIDatagram: Destination resource 13 unsupported.
2020-07-17T10:24:54.010-04:00| vcpu-1| I005: VMCIDatagram: Destination resource 13 unsupported.
2020-07-17T10:25:06.742-04:00| vcpu-2| I005: USB: Setting needsPeriodicExecFrame to TRUE for xhci
2020-07-17T10:25:09.205-04:00| vcpu-3| I005: USB: Clearing needsPeriodicExecFrame for xhci
2020-07-17T10:25:09.205-04:00| vcpu-3| I005: USB: Clearing needsPeriodicExecFrame for xhci
2020-07-17T10:25:32.809-04:00| vmx| I005: Progress -1% (msg.HGFileCopy.prepareread)
2020-07-17T10:25:32.841-04:00| vcpu-1| I005: HGFileCopyCreateSessionCB: Successfully created the session.
2020-07-17T10:25:32.844-04:00| vcpu-1| I005: Progress 0% (msg.HGFileCopy.ReadFile)
...
2020-07-17T10:25:33.649-04:00| vcpu-2| I005: Progress 29% (msg.HGFileCopy.ReadFile)
...
2020-07-17T10:25:34.047-04:00| vcpu-1| I005: Progress 71% (msg.HGFileCopy.ReadFile)
...
2020-07-17T10:25:34.318-04:00| vcpu-3| I005: Progress 101% (none)

[NoelJB]

@oliverkurth , when you ran your test, was the host MS-Windows or Linux? I am suspecting that the problem is on the host side.

[oliverkurth]

when you ran your test, was the host MS-Windows or Linux

Personally neither, I use Fusion. This should have been tested for other hosts though. I will file an internal bug to the Workstation team.

[NoelJB]

@oliverkurth , no worries. FWIW, I just tested it on a LM 20 host with the same results. I'll try the same guest on an MS-Windows host as soon as I can.

[horshack-dpreview]

FYI I discovered the bug occurs for vmhgfs-fuse I/O sizes >= 64K. You can work around the issue by adding a max_write=61440 to the mount options in fstab (64K - 4K). For example:

.host:/ /mnt/hgfs fuse.vmhgfs-fuse noauto,allow_other,max_write=61440 0 0

More details here: #437 (comment)

[NoelJB]

I will file an internal bug to the Workstation team.

Any news?

@oliverkurth , actually I may be able to tell what is wrong. Consider that the error on the host says: Error when getting information for file “/fdHklT/MyTestDoc.docx”: No such file or directory

It occurred to me that this might be literal, and someone made a code change so that it fails to prepend the path to include /tmp/VMwareDnD/. And it appears that may be exactly what someone has done, because when I check /tmp/VMwareDND, look what I see:

:/tmp/VMwareDnD$ ls -ltr
total 0
lrwxrwxrwx 1 noel noel 45 Aug 14 20:35 Dch0IW -> /home/noel/.cache/vmware/drag_and_drop/Dch0IW
lrwxrwxrwx 1 noel noel 45 Aug 14 20:35 UoPABT -> /home/noel/.cache/vmware/drag_and_drop/UoPABT
lrwxrwxrwx 1 noel noel 45 Aug 17 08:59 si0XxS -> /home/noel/.cache/vmware/drag_and_drop/si0XxS
lrwxrwxrwx 1 noel noel 45 Aug 17 11:02 fdHklT -> /home/noel/.cache/vmware/drag_and_drop/fdHklT

:/tmp/VMwareDnD$ cd fdHklT/

:/tmp/VMwareDnD/fdHklT$ ls -ltr
total 5936
-rwx------ 1 noel noel 6077245 Aug 17 08:58 'MyTestDoc.docx'
`
There is the file. Checking the other sessions shows that there are files under all of the ~/.cache/vmware/drag_and_drop/ directories.

[NoelJB]

@oliverkurth, this is still broken with VMware Workstation 16, even with an MS-Windows guest using VMware Tools 11.1.5.

Same exact thing I noted in the previous post. The host dialog reports looking at /session/filename, when it should be looking at /tmp/VMwareDnD/session/filename.

[denji]

Another problem is that ~/.cache/vmware($HOME/.cache/vmware) is filling up the disk, and linux overload will not help eliminate temporary files.

[NoelJB]

@denji , that's almost certainly connected, since they fail to move the file out of the cache into the target location.

I've looked over the code for open-vm-tools, but unfortunately, it appears that the relevant code is in vmware-vmx, which is not in source form anywhere that I can see, and @oliverkurth and VMware have gone silent.

[ravindravmw]

Thanks for your patience. I have notified the concerned developers. I hope someone will get back on this issue soon.

[suiahae]

I ran into the same problem on Fedora. The details of the problem are exactly the same as what you said above, I hope VMware will solve it as soon as possible.

[HMahdikhani]

I have faced the same error on Ubuntu 20.04 (5.6.0-1034) and both VMWare Workstation Pro 16 and 16.1. The guest is Windows 8 64. Everything can be copied from Ubuntu to Windows guest machine, but from Windows to Ubuntu only small size files can be copied. I have tried different solutions, including modifying /home/[username]/.cache/vmware/drag_and_drop permission, guest isolation, and updating vmtools.

[Ex-Origin]

Same as above.
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
Linux ubuntu 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[TCROC]

I can confirm that I am also facing this issue

[ovakisan]

Have this issue on Ubuntu 20.04, was it fixed somehow, anyone have more information, this has been opened for some time now.

[70nyIT]

Same problem here. Guest is Ubuntu (20.4), host is Ubuntu (20.4). Can copy from host to guest, but not from guest to host.

[xspellsteal]

Same issue, Guest is RHEL 8, Host is Windows.

[rbeede]

I can reproduce this issue if I try to copy a file with a filename like test##.docx from a host (Win 10) to a guest (Ubuntu 20.04).

The file does make it onto the guest, but the copy operation fails because everything after test (the ##.docx part) is not translated into the path.

[leoiwa]

I copy file from host(Manjaro) to guest, Same exact thing I noted in the previous post. The host dialog reports looking at /session/filename.vmware version is 16.2.3

[NoelJB]

Many people can, naturally, reproduce the problem, which has not been fixed since Workstation 15.5.5. As I am given to understand, VMware laid off many of the developers who worked on the desktop products, and are in the process of being bought by Broadcom, who has already announced plans to make VMware products subscription based. It seems that there is little attention given to Workstation.

I've used VMware since '98 or '99, was a beta tester, and an active participant in the community, to the point where they sent me one of their polo shirts. The current situation, with lack of support or even interest on their part is extremely sad.

I would love for a live VMware staffer to correct misgivings, and let us know the status of this two year old outstanding defect, which should not have taken even an hour of programming time to fix.

[horshack-dpreview]

Many people can, naturally, reproduce the problem, which has not been fixed since Workstation 15.5.5. As I am given to understand, VMware laid off many of the developers who worked on the desktop products, and are in the process of being bought by Broadcom, who has already announced plans to make VMware products subscription based. It seems that there is little attention given to Workstation.

I've used VMware since '98 or '99, was a beta tester, and an active participant in the community, to the point where they sent me one of their polo shirts. The current situation, with lack of support or even interest on their part is extremely sad.

I would love for a live VMware staffer to correct misgivings, and let us know the status of this two year old outstanding defect, which should not have taken even an hour of programming time to fix.

FYI, the issue is fixed in 15.5.7 for me and others. Reference:
#437 (comment)

[NoelJB]

FYI, the issue is fixed in 15.5.7 for me and others. Reference: #437 (comment)

It appears that you are confusing that issue related to HGFS with this issue related to drag 'n drop between Guest and Host. See #435 (comment) for the underlying issue (the filepath is wrong).

HGFS works. That's not the point of this issue.

[hellodears]

It's the middle of 2023, using VMware 17.0.0 and a fully updated Windows 11 host with a Manjaro (KDE Plasma/Wayland) guest VM and drag & drop still doesn't work. What. a. mess. For shame.

[NoelJB]

Ping!

I'm even one of those customers who is paying for supporting, this defect still has not been fixed.

[teji24]

same problem here BUT on same host (debian 11), i have some VM accepting C/P to VM and others not.
cannot find why...
i tried 3 new VM with same iso install than a C/P not-working VM. and all 3 work for C/P !!!!
Then i was thinking "new VM work, old not"... (REM : old = created on old VMware version.
i created a new VM, with old vmdk disk from "C/P not working VM". then only the "c" disk is old ... not working !!!
desinstall/resinstall vmwtools.... not working !!!
cannot understand why some work and others not....

[rbeede]

May be related to #587

[teji24]

May be related to #587

probably not, here it's not related to filename (containing "#") to copy/paste.
"aaa.txt" give same error... But thanks for your answer !