open-vm-tools icon indicating copy to clipboard operation
open-vm-tools copied to clipboard

shared folder doesn't work on CentOS guest

Open noelo-cohelo opened this issue 2 years ago • 4 comments

Describe the bug

I've seen many content in the internet about how to mount shared folder. I wasn't able to make it work, but here I would like to focus on the fact that it doesn't work out of the box as I understand it should. Every advice regarding how to make it work with manual mounting will be just a workaroud for me.

Reproduction steps

VMWare Workstation 16 Player

open-vm-tools 11.0.5.17716 (build-15389592)

fuse: version 1.6.9.0 FUSE library version: 2.9.2 fusermount version: 2.9.2 using FUSE kernel interface version 7.19

kernel 3.10.0-1160.83.1.el7.x86_64

CentOS 7.9

Of course I've enabled add added a shared folder on VM settings.

Expected behavior

shared folder visible under the default location /mnt/hgfs; able to exchange files between guest and host using this folder without running any additional commands

Additional context

dragging and dropping and common clipboard work

noelo-cohelo avatar Apr 14 '23 10:04 noelo-cohelo

How it works just out of the box is affected by Linux vendor packaging choices.

When the CentOS ISO is installed from the ISO, it comes with open-vm-tools 11.0.5 preinstall and the vmtoolsd process will start when the system is booted. If not running on a VMware hypervisor, the vmtoolsd process will quietly terminate itself.

To do a fuse mount, a systemd process (run-vmblock\x2dfuse.mount) is needed, but it is only needed when booting on a VMware hypervisor and only Workstation or Fusion. The CentOS 7.x open-vm-tools provides that systemd service, but it is preset disabled by the vendor.

systemctl status run-vmblock\x2dfuse.mount

● run-vmblock\x2dfuse.mount - VMware vmblock Fuse Mount Loaded: loaded (/usr/lib/systemd/system/run-vmblock\x2dfuse.mount; disabled; vendor preset: disabled) Active: inactive (dead) Where: /run/vmblock-fuse What: vmware-vmblock-fuse Docs: https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/vmblock-fuse/design.txt

To enable and start this systemd service on your WS Player VM, follow the steps outlined in VMware KB 746710.

Make sure vmware-user-suid-wrapper has the suid bit set as directed in the KB.

johnwvmw avatar Apr 20 '23 04:04 johnwvmw

I understand why the vendor disabled it and I understand that it's not fault of open-vm-tools. But would you agree that this is something that VMsare Workstation Player should do (I mean running systemd process) when setting shared folder to enabled? Just wondering if I could report it to them to make user lives easier.

The link to VMware knowledge base gives me 404 not found. Is it available for everyone?

noelo-cohelo avatar Apr 20 '23 11:04 noelo-cohelo

Appologies for the bad KB article link. Please try https://kb.vmware.com/s/article/74671.

It would be nice and very convenient if Workstation and Player "could" do what you suggested. But I am afraid that is not possible because of a multitude of factors such as:

  • Linux daemon management varies by vendor and the version of their Linux releases.
    • Most Linux releases use systemd, others and especially older Linux releases may be using initd scripts.
  • The run-vmblock script mentioned here is released by a different name on other vendors' Linux.
  • Some Linux releases prefer the /mnt only be used for temporarily mounted storage; not a permanently mounted fuse file system. They choose not provide the fuse mount systemd file; the user may need to add from the KB article.
  • Graphic environment choices (Xorg, Wayland) along with desktop choices (Gnome, KDE Plasma, XFce, Unity, ...) introduces a much larger variety of configuration possibilities.

And your preferreAppologies for the bad KB article link. Please try https://kb.vmware.com/s/article/74671.

It would be nice and very convenient if WS "could" do what you suggested. But I am afraid that is not possible because of a multitude of factors such as:

  • Linux daemon management varies by vendor and the version of their Linux releases.
    • Most Linux releases use systemd, others and especially older Linux releases may be using initd scripts.
  • The run-vmblock script mentioned here is released by a different name on other vendors' Linux.
  • Some Linux releases prefer the /mnt only be used for temporarily mounted storage; not a permanently mounted fuse file system. They choose not provide the fuse mount systemd file; the user may need to add it from the KB article.
  • Graphic environment choices (Xorg, Wayland) along with desktop choices (Gnome, KDE Plasma, XFce, Unity, ...) introduces a much larger variety of configuration possibilities.

And your "convienent" Linux VM setup can be an inconvience or annoyance to other users.

With hosted products (WS, Player, Fusion), vSphere and open-vm-tools releases happening asyncronously, we try to provide guidance through various known differences or oddities in Release Notes or KB articles such as the one mentioned. Newer Linux releases or updates with different versions of open-source packages can introduce new issues and for these situations we revise existing KBs or issue new KBs as warranted.

If you have problems or suggestions, please ask. Also let us know if an existing KB article may need updating.

johnwvmw avatar Apr 20 '23 18:04 johnwvmw

So is this the activation of this process the only thing one should do after enabling shared folders from virtual machine settings? I'm asking cause I activated the process and the folder is not there.

I feel that the necessity of this process activation should be mentioned here: https://docs.vmware.com/en/VMware-Workstation-Player-for-Windows/16.0/com.vmware.player.win.using.doc/GUID-D6D9A5FD-7F5F-4C95-AFAB-EDE9335F5562.html (of course not the specific process from my case, but rather the general information that one has to perform additional steps like mounting on the guest, with further links dependent on the environment).

Also, the funny thing about the article you linked (https://kb.vmware.com/s/article/74671) is that it only mentions copy-paste and drag-drop, while those were working on my machine without enabling the process. If this article is indeed for shared folders, I think the name should reflect this.

noelo-cohelo avatar Aug 11 '23 09:08 noelo-cohelo