DEV Community

Cover image for The Case of the Vanishing Clipboard: Debugging a VirtualBox Guest Additions Conflict on Kali Linux
Adeoye Malumi
Adeoye Malumi

Posted on

The Case of the Vanishing Clipboard: Debugging a VirtualBox Guest Additions Conflict on Kali Linux

#linux #virtualbox #debugging #learning

If you've ever run a Linux VM in VirtualBox and had copy-paste between your host and guest just... stop working, this post is for you. What started as a simple "my clipboard isn't syncing" turned into a proper detective story involving conflicting installations, a kernel module stuck "in use," and a systemd service quietly failing on every single boot. Here's the full walkthrough — what broke, how we figured out why, and how we fixed it for good.

The Setup

I run a Kali Linux VM inside VirtualBox on my host machine, mainly as a home lab for practicing infrastructure and security tooling. One day, shared clipboard between my host and the guest just stopped working. My first instinct was to run apt update && apt upgrade — but nothing changed. That's actually an important clue we'll come back to: apt upgrades regular packages, but it does not automatically rebuild or reinstall VirtualBox Guest Additions, which is the component actually responsible for clipboard sharing.

What Actually Makes Clipboard Sharing Work

Before diving into the fix, it helps to understand the moving parts, since "clipboard sync" isn't one single thing — it's three things working together:

  1. The vboxguest kernel module — a driver inside the guest OS that lets it talk to VirtualBox itself.
  2. VBoxService — a background daemon (runs as root) that handles ongoing communication with the hypervisor: time sync, clipboard, shared folders, and more.
  3. VBoxClient — a per-user process that specifically handles the clipboard and display integration, and talks to VBoxService through the kernel module.

If any one of these three breaks, clipboard sharing breaks — and the error messages don't always make it obvious which one is the culprit.

First Round: The Standard Checklist

We started with the usual suspects for VirtualBox clipboard issues:

  • Enable Bidirectional clipboard: In the VM window, under Devices > Shared Clipboard, this needs to be set to Bidirectional (or the direction you want). It resets sometimes after VirtualBox updates.
  • Check Guest Additions version: A mismatch between the host's VirtualBox version and the guest's installed Guest Additions is a very common cause of weird behavior.
  • Restart the clipboard client: Running VBoxClient --clipboard fresh can fix cases where the process silently died.
  • Check for Wayland: On newer Ubuntu-based systems, the default desktop session uses Wayland instead of X11, and VirtualBox's clipboard sharing doesn't work reliably under Wayland. Kali defaults to X11, so this wasn't our issue here, but it's worth checking with echo $XDG_SESSION_TYPE if you're on Ubuntu.

None of these resolved it. Time to dig deeper.

The Real Clue: VbglR3InitUser failed: VERR_FILE_NOT_FOUND

Running VBoxClient --clipboard directly produced this error. Breaking it down for anyone unfamiliar with VirtualBox internals:

  • VbglR3InitUser is the function VBoxClient uses to open a connection to the kernel module.
  • VERR_FILE_NOT_FOUND means it was trying to open a device file that didn't exist.

In Linux, kernel drivers often expose themselves to user programs as special files under /dev/. VirtualBox's guest driver should create /dev/vboxguest and /dev/vboxuser. Sure enough:

ls -la /dev/vboxguest
# ls: cannot access '/dev/vboxguest': No such file or directory
Enter fullscreen mode Exit fullscreen mode

But here's the twist — the module itself was loaded:

lsmod | grep vboxguest
# vboxguest   53248  1
Enter fullscreen mode Exit fullscreen mode

So the driver was active in the kernel, but it never created the device file the userspace tools needed to talk to it. That's a very different problem from "module isn't installed," and it pointed toward something interfering with the service responsible for creating those device nodes — not the module itself.

Finding the Actual Root Cause

Checking the relevant systemd service told the real story:

systemctl status vboxadd-service
# Active: failed (Result: exit-code)
Enter fullscreen mode Exit fullscreen mode

This service was owned by a completely separate Guest Additions installation living at /opt/VBoxGuestAdditions-7.2.6 — installed manually at some point via VirtualBox's "Insert Guest Additions CD image" option.

Meanwhile, running:

dpkg -l | grep virtualbox-guest
Enter fullscreen mode Exit fullscreen mode

showed Kali's own apt-managed packages (virtualbox-guest-utils, virtualbox-guest-x11) already installed, at a different version (7.2.8 vs 7.2.6).

This was the root cause: two separate Guest Additions installations coexisting on the same VM. Kali Linux ships with its own guest-additions packages pre-tuned for its kernel. Running the classic CD-based installer on top of that creates a conflict — two sets of init scripts, two sets of udev rules, and two services fighting over the same kernel module. The manually-installed one was failing to start, and because it "won" the race for creating the device nodes, clipboard support broke entirely — even though the apt-managed packages were sitting right there, perfectly capable of doing the job correctly.

The lesson for Kali users specifically: don't run the manual Guest Additions CD installer if you're on a Kali VM. Stick to sudo apt update && sudo apt install --only-upgrade virtualbox-guest-utils virtualbox-guest-x11 to keep Guest Additions current.

Fixing It, Step by Step

1. Stopping the broken service 

sudo systemctl stop vboxadd-service
sudo systemctl disable vboxadd-service
Enter fullscreen mode Exit fullscreen mode

2. Hitting a wall: "Module is in use"

The plan was to unload and reload the kernel module cleanly:

sudo modprobe -r vboxsf vboxguest
Enter fullscreen mode Exit fullscreen mode

This failed with FATAL: Module vboxguest is in use. Something still had it open. In Linux, you can't unload a kernel module while a process is actively using it — so we needed to find that process first:

ps aux | grep -i vbox
# root ... /usr/sbin/VBoxService
Enter fullscreen mode Exit fullscreen mode

VBoxService — the background daemon mentioned earlier — was still running and holding the module open. Even after killing it with pkill, it turned out a systemd unit would just start it right back up, so the actual fix was to stop the service, not just the process:

sudo systemctl stop vboxadd.service vboxadd-service.service
sudo pkill -9 VBoxService
ps aux | grep -i vbox   # confirmed nothing left running
Enter fullscreen mode Exit fullscreen mode

3. Reloading the module cleanly

With nothing holding it open anymore, the reload finally worked:

sudo modprobe -r vboxsf vboxguest
sudo modprobe vboxguest vboxsf
lsmod | grep vboxguest   # module back and loaded
Enter fullscreen mode Exit fullscreen mode

And the moment of truth:

ls -la /dev/vboxguest /dev/vboxuser
# crw-rw---- 1 root root 10, 262 ... /dev/vboxguest
# crw-rw-rw- 1 root root 10, 263 ... /dev/vboxuser
Enter fullscreen mode Exit fullscreen mode

Both device nodes existed. The kernel side of the problem was solved.

4. Cleaning up the leftover conflict

We tried to run the manual installer's own uninstall script to remove the conflicting install cleanly:

sudo /opt/VBoxGuestAdditions-7.2.6/uninstall.sh
Enter fullscreen mode Exit fullscreen mode

Interestingly, the directory no longer existed — it had already been partially removed at some earlier point, leaving only stale systemd references behind (a case of "the crime scene's been cleaned, but the paperwork's still open"). Since there were no leftover /etc/init.d/ scripts either, the fix was simply clearing systemd's memory of the old failed units:

sudo systemctl stop vboxadd.service vboxadd-service.service
sudo systemctl daemon-reload
sudo systemctl reset-failed
Enter fullscreen mode Exit fullscreen mode

5. Reinstalling clean and rebooting

To make sure everything was consistent, we reinstalled the apt-managed packages and rebooted — the real test of whether this was fixed for good, not just patched until the next restart:

sudo apt install --reinstall virtualbox-guest-utils virtualbox-guest-x11
sudo reboot
Enter fullscreen mode Exit fullscreen mode

6. Testing the clipboard

After reboot:

VBoxClient --clipboard
ps aux | grep -i vbox
Enter fullscreen mode Exit fullscreen mode

VBoxService, VBoxDRMClient, and VBoxClient were all running cleanly. Copy-paste between host and guest — both directions — worked immediately.

Bonus Round: Shared Folders

While we were in there, we set up shared folders too, using the same underlying vboxsf kernel module we'd just fixed.

  1. Add the folder in VirtualBox: Devices > Shared Folders > Shared Folders Settings, add the host path, name it, and check both Auto-mount and Make Permanent.
  2. Join the vboxsf group: Regular users can't access shared folders by default. 
   sudo usermod -aG vboxsf $USER
Enter fullscreen mode Exit fullscreen mode

Group changes don't apply to an already-running session, so this needs a logout/login or reboot to take effect.

  1. Find the mount point: On generic Debian-based systems, auto-mounted folders usually appear at /media/sf_<foldername>. On Kali specifically, they show up directly inside your home directory instead — in our case, /home/osboxes/VM-Share. Worth checking both locations if one doesn't exist.
  2. Verify it worked: 
   mount | grep vboxsf
   ls -la /home/osboxes/VM-Share
Enter fullscreen mode Exit fullscreen mode

The listing showed real files from the host, owned by the vboxsf group with read/write permissions — confirming full access, not just visibility.

Final Verification

After the reboot, we ran three checks to confirm everything was genuinely fixed rather than just patched in the moment:

systemctl list-units --all | grep -i vbox   # no failed vboxadd units
ls -la /dev/vboxguest /dev/vboxuser         # both device nodes present
lsmod | grep vboxguest                      # module loaded, in use by vboxsf
Enter fullscreen mode Exit fullscreen mode

All clean. No stale services, working clipboard, working shared folders — and all of it confirmed to survive a fresh boot.

Key Takeaways

  • apt upgrade does not manage Guest Additions. It's a separate component from regular system packages, and won't be touched by a normal update.
  • Never mix installation methods. If your distro (like Kali) ships its own Guest Additions packages, don't also run the manual CD installer — pick one and stick with it.
  • A loaded kernel module isn't the whole picture. vboxguest being in lsmod doesn't guarantee its device files exist — those depend on a service actually creating them.
  • "Module is in use" means something's holding it open. Find that process (ps aux | grep) and stop the service managing it, not just the process, or it'll respawn.
  • Kali's shared folder auto-mount path differs from generic Debian. Check your home directory, not just /media/sf_*, if the expected mount point doesn't show up.

What looked like a simple "clipboard is broken" turned out to be a genuinely interesting systems debugging exercise — tracing the problem from a symptom, through kernel module state, into a systemd service, and finally down to a two-installations-at-once root cause. That's the kind of troubleshooting that actually teaches you how these pieces fit together.

Top comments (0)