Installed and running are two different claims, and VMware Tools problems live in the gap between them. This page gives you the checks that close that gap: ask the service, ask the package manager, ask the tools themselves - and then the only verdict that finally counts, whether the features actually work.
Maybe you inherited this VM, maybe you installed the tools months ago, maybe the install scrolled past too fast to trust. Either way, verification is a two-minute job with four independent witnesses: the systemd service, the package database, the tools' own version report, and the behaviour of the desktop itself. Run them in this order and you will know - not guess - whether VMware Tools is installed, running, and doing its job in your Ubuntu VM.
The heart of the tools is a background daemon called vmtoolsd, managed by systemd as the open-vm-tools service. Ask it directly:
systemctl status open-vm-tools --no-pagerpgrep -a vmtoolsd - one or more running vmtoolsd lines should come back.If the service says inactive or failed, the tools are not running regardless of what was installed - restart it with sudo systemctl restart open-vm-tools and check again.
Service states can mislead after odd shutdowns; the package database does not. Run dpkg -l | grep open-vm and read the list. On a desktop VM you want two lines, open-vm-tools and open-vm-tools-desktop, each starting with ii for installed. No lines at all means the tools were never installed on this VM - go back to the install guide. One line on a desktop VM means the classic half-install: the engine is present, the features are not, and the fix is adding the -desktop package.
vmtoolsd --version prints the running daemon's version and build. This check earns its place in two situations: confirming an update actually took effect (compare before and after an apt upgrade), and reporting an exact version when you ask for help - "the tools don't work" gets fixed far faster as "open-vm-tools 12.5 on Ubuntu 24.04". If the command itself is not found, that is also an answer: this VM has no tools installed, whatever its history claims.
Services can run while features silently fail, so finish with behaviour:
All four passing is the real definition of "VMware Tools is working". A failure isolated to one feature points at that feature's setting - for example, copy-paste switched off under Guest Isolation in the VM's options - rather than at the whole installation.
Finally, VMware's own view: Workstation shows the tools state for a selected VM, and ESXi reports "VMware Tools is running" along with the guest's IP address once the daemon checks in. One honest catch explains many false alarms: the desktop features agent starts only after a user logs in. A VM sitting at the Ubuntu login screen can legitimately show tools as not fully running, then flip to healthy the moment you sign in. Judge the host's report only after login - and if everything above passes while the host still complains, a full shutdown and cold start of the VM usually reconciles them.
If your checks show the tools are missing entirely, the video's one-command install is the fastest way back - watch it and follow along.
▶️ Watch Full VideoBoth, in layers. The version answer proves the base daemon is installed and alive. Resize, however, is delivered by the desktop package's session agent, which needs the -desktop package installed and a fresh login after installing it. Check dpkg for both packages, add the desktop one if it is missing, reboot, and retest - that sequence fixes the great majority of running-but-not-resizing VMs.
Restart it and watch the result: sudo systemctl restart open-vm-tools, then check the status again. If it fails repeatedly, reinstalling over the top is the cleanest repair - sudo apt install --reinstall open-vm-tools-desktop - followed by a reboot. Persistent failure after a reinstall is rare and usually points at a wider problem with the VM's system services rather than the tools themselves.
Usually both, at different moments. The host judges by the daemon's heartbeat and the logged-in session agent; at the login screen, or in the first moments after boot, the report lags behind reality. Log in, wait half a minute, and check again. If the features work and the service shows active, trust the guest-side evidence - and a cold shutdown and start of the VM clears a genuinely stale host report.