How can I fix VirtualBox not accessing my host COM port?

Serial Communication
1

I’m running a Windows 11 host with a Linux guest in VirtualBox and I can’t get the guest OS to access the host’s physical COM port even after enabling a serial port in the VM settings. The device shows up on the host and works in other apps, but the guest never sees it or times out when I try to connect. I need this working to talk to an embedded device over serial for development and debugging. What could be misconfigured, and what settings or drivers should I check to get reliable COM port access in VirtualBox?

2

VirtualBox + real serial ports on Windows 11 is a bit of a headache, so here’s the checklist that usually fixes it:

  1. Make sure nothing on the host has the COM port open

    • Close PuTTY, Tera Term, Arduino IDE, vendor tools, anything that might grab COM3 or whatever port you need.
    • Check Device Manager: Ports (COM & LPT) and confirm the actual COM number. Use that exact number in VirtualBox.

  2. Configure the VM serial port correctly
    In VirtualBox settings for your VM:

    • Go to Serial Ports.
    • Check Enable Serial Port.
    • Port Number: COM1 (inside the guest).
    • Port Mode: Host Device.
    • Port/File Path: COM3 or whatever you saw in Device Manager. No \\.\ prefix, just the name typically works on Windows.
    • Make sure the VM is powered off while changing this.

  3. Match the guest device to the VirtualBox port
    In Linux guest:

    • COM1 in VirtualBox usually maps to /dev/ttyS0.
    • Try:
      sudo dmesg | grep tty
ls -l /dev/ttyS*
sudo minicom -D /dev/ttyS0
    • If you set Port 2 in VirtualBox, that usually becomes /dev/ttyS1 and so on.

  4. Run VirtualBox “as Administrator” on the host
    Windows sometimes blocks low level access to COM ports if VBox isn’t elevated.

    • Close VirtualBox.
    • Right click VirtualBox icon → “Run as administrator”.
    • Try the VM again.

  5. Check VBox logs for serial errors

    • In VirtualBox Manager: right click VM → Show Log.
    • Search for Serial or your COM name.
      If you see stuff like cannot open host device COM3 then Windows is blocking it or something else has it open.

  6. If it’s a USB to serial adapter, use USB passthrough instead
    Host Device serial in VBox is flaky with some USB adapters.

    • In VM settings → USB.
    • Enable USB 2.0 or 3.0 (with Extension Pack).
    • Add a filter for your USB serial device.
    • Boot the guest and it should appear as /dev/ttyUSB0 or /dev/ttyACM0.
      This is usually more reliable than COM passthrough on Windows 11.

  7. When native COM passthrough just won’t cooperate
    If your setup is picky or you need to share that COM port across several VMs or apps, a software bridge works better:

    • Install Serial to Ethernet Connector on the Windows 11 host.
    • It creates a virtual serial port over TCP so the guest can connect via network rather than raw COM.
    • Inside the Linux guest you just talk to a TCP socket (for example with socat or your app), and the host forwards that to the real COM port.

    There’s a solid walkthrough here on getting a Windows host serial port into a VM using network-based access:
    make your VirtualBox serial setup actually work

    That approach often sidesteps all the “host has locked COM3” or permission junk that VirtualBox runs into on Windows.

If none of that works, post your exact VirtualBox serial settings and the dmesg output from the guest, plus what Device Manager shows on the host. Nine times out of ten it’s either the wrong COM number or some other app hogging the port.

How can I fix VirtualBox not accessing my host COM port?
How can I fix VirtualBox not accessing my host COM port?1536×668 149 KB

2 Likes
3

VirtualBox + serial on Windows 11 is like trying to use dial‑up in 2025: in theory it works, in practice it just screams at you in logs.

@sterrenkijker already covered the sane checklist. Let me pile on some “weird but actually fixes it” stuff that I keep running into, and occasionally disagree a bit.

1. Stop trusting the GUI, check what VBox really did

Sometimes the GUI says “Host Device: COM3” but the VM is actually trying something else.

  1. Power off the VM.
  2. Open a PowerShell / cmd as admin in the VirtualBox install dir.
  3. Run:
    VBoxManage showvminfo 'Your VM Name' | findstr /i serial
    You should see something like:
    UART 0: I/O base 0x3F8, IRQ 4, attached to host device 'COM3'
    If it says “disabled” or some random path, the GUI setting didn’t stick.

If it doesn’t match what you expect, explicitly set it:

VBoxManage modifyvm 'Your VM Name' --uart1 0x3F8 4 --uartmode1 host COM3

I’ve had cases on Windows 11 where the GUI let me choose the port but VBoxManage was the only thing that actually applied it.

2. Watch out for stupidly high COM numbers

If your adapter is on COM12 or COM18, VirtualBox sometimes chokes on that even though Windows itself is fine.

  • In Device Manager, reassign the port to a low number:
    • Right‑click the port → Properties → Port Settings → Advanced.
    • Change to COM3 / COM4.
  • Update VirtualBox to use that new COM number.

Yes, it should handle COM14. No, it doesn’t always.

3. Check Windows access control on the COM device

On some Windows 11 builds with tight corporate policies, processes without elevated rights or proper device permissions cannot open the COM port even if you run VirtualBox as admin.

Try this:

  1. Open Event Viewer → Windows Logs → System.
  2. Reproduce the failure by starting the VM.
  3. Look for entries about “device access denied” or “\Device\SerialX” type messages around that time.

If you see those, it’s not just “port in use,” it’s Windows outright blocking it due to group policy / Defender / some paranoid endpoint protection. In that case, you may never get stable direct COM passthrough and you’re better off with a network bridge to the serial device.

4. In the guest, verify actual traffic, not just device presence

Linux will happily show /dev/ttyS0 all day even if nothing real is behind it.

Inside the guest:

sudo strace -f -e trace=open,ioctl,read,write minicom -D /dev/ttyS0

Or your app instead of minicom.
You want to see:

  • Successful open on /dev/ttyS0
  • read / write calls that don’t instantly fail with EIO or EBADF

If open fails, VBox never gave the guest a working link to the host COM device. That points back to host config or Windows permissions, not Linux.

5. Explicitly match IRQ / IO base if the guest is old-school picky

Most modern Linux guests auto‑detect, but some older kernels or weird embedded distros are picky.

In VirtualBox Serial Ports:

  • Port 1 → I/O Port: 0x3F8, IRQ: 4 → this should look like a classic COM1.
  • Make sure your Linux guest isn’t trying /dev/ttyS1 or non‑standard probes.

You can force it in the kernel cmdline (if needed):

  • Add to GRUB kernel line: 8250.nr_uarts=4
  • Or if it’s ignoring the port, confirm with:
    sudo setserial -g /dev/ttyS0

I’ve seen people complain “/dev/ttyS0 exists but no data” and it turned out the UART wasn’t actually probed properly.

6. Mild disagreement with the “USB passthrough is always better” angle

What @sterrenkijker said about USB passthrough being more reliable is often true, but not universal:

  • Some flaky USB‑serial chips (random CH340 clones, cheap PL2303) behave worse when passed through to Linux than when handled by the more tolerant Windows driver and only the serial stream is forwarded.
  • If you need the vendor Windows driver features (special control lines, firmware loader, etc.), raw COM passthrough or a network bridge lets Windows own the hardware and the guest just sees a stream.

So yeah, if USB passthrough works for your specific dongle, use it. If not, don’t be surprised.

7. When COM passthrough just keeps fighting you: use a network bridge

This is where a lot of people finally stop suffering and things start actually working.

On the Windows 11 host, install a reliable serial over network tool. One good option is Serial to Ethernet Connector. Instead of VirtualBox fighting with the COM port directly, Windows fully owns the physical port and exports it over TCP.

Conceptually:

  • Windows host:
    • COM3 is opened by Serial to Ethernet Connector.
    • It listens on something like 127.0.0.1:5000.
  • Linux guest:
    • You connect to that TCP port and treat it as your serial line.

Example on the guest with socat:

sudo apt install socat
socat pty,link=/dev/ttyV0,raw,echo=0 tcp:192.168.56.1:5000

Now /dev/ttyV0 in the guest behaves like the host’s COM3.

If you want an easy way to grab the installer, take a look at
advanced serial-over-network tools for Windows
and grab Serial to Ethernet Connector there. It tends to bypass all the “VirtualBox cannot open host device” nonsense because VirtualBox never touches the COM device directly.

This approach is also great if:

  • You want to share the same serial port between host apps and the VM.
  • You run multiple VMs.
  • You’re on a locked‑down corporate Windows where raw device access from VBox is cursed.

8. Quick triage checklist so you’re not stuck all day

In order I’d try:

  1. Confirm with VBoxManage showvminfo that the UART is really set to host COMx.
  2. Drop the host port to a low COM number (3/4).
  3. Check Event Viewer for blocked device access.
  4. In Linux guest, use strace or at least check dmesg when opening /dev/ttyS0.
  5. If it still fails or is unreliable, stop wasting time and move to Serial to Ethernet Connector + TCP bridge.

If you can share:

  • Exact COM number on host
  • Output of VBoxManage showvminfo around “UART”
  • dmesg | grep tty and the error from your terminal program in Linux

someone will probably spot the last missing bit pretty fast.

4

Couple of extra angles that might help, building on what @sonhadordobosque and @sterrenkijker already covered.

1. Check if you are hitting the “Windows 11 + VBox driver” bug

On some Win11 builds, VirtualBox’s low‑level driver that talks to COM devices is flaky, especially after cumulative updates.

Try:

  1. Completely uninstall VirtualBox.
  2. Reboot.
  3. Install the latest VirtualBox version, plus the matching Extension Pack.
  4. Reboot again before testing serial.

I have seen setups where COM passthrough only started working after a clean reinstall because the VBoxDrv / VBoxUSBMon drivers were out of sync with the host’s updated kernel.

2. Disable “serial-friendly” but hostile host tools

You already know to close PuTTY etc., but there are some less obvious COM grabbers:

  • Vendor updater services for microcontrollers or dev boards.
  • “Auto‑recognition” features in STM32, NXP, TI tools.
  • Background monitor tools that probe every COM on startup.

Try a clean boot:

  1. msconfig → disable all non‑Microsoft services.
  2. Disable all startup items in Task Manager.
  3. Reboot, then test VirtualBox serial again.

If it works in that stripped mode, re‑enable services gradually until you find the COM hog.

3. Avoid mixing VirtualBox networking with serial tunneling at first

Some people immediately try to combine bridged networking, USB passthrough, and serial passthrough in one go. VirtualBox usually survives this, but debugging does not.

For diagnosis, keep it boring:

  • One serial port in VBox.
  • No USB serial passthrough at the same time.
  • Plain NAT networking.

Once you know COM passthrough works, then add fancy networking or USB filters.

4. When you want reliable access instead of fighting COM: use a TCP bridge

Here I slightly disagree with the implicit “fix COM passthrough first” stance. If your end goal is “Linux talks to the device,” not “VirtualBox must own the COM handle,” you can skip a lot of pain.

Serial to Ethernet Connector on the Windows host is a solid way to do that:

How it works conceptually

  • Windows opens the real COM port (e.g. COM3).
  • Serial to Ethernet Connector exposes that port as a TCP server.
  • Your Linux guest connects to host-ip:port and treats it like a serial line.

Inside Linux you can create a pseudo‑TTY:

sudo apt install socat
socat pty,link=/dev/ttyV0,raw,echo=0 tcp:192.168.56.1:5000

Now /dev/ttyV0 is your virtual serial device.

Pros of Serial to Ethernet Connector

  • Windows keeps full control of the hardware driver, which is usually more stable with odd USB‑serial chips.
  • Works with multiple VMs or host + VM sharing the same port (depending on mode).
  • Bypasses VirtualBox’s direct COM access issues completely.
  • Survives host OS updates better, since it uses standard networking, not VBox’s COM layer.

Cons of Serial to Ethernet Connector

  • Extra component to install and configure on the host.
  • Adds minimal latency compared to direct COM passthrough.
  • You have to manage a TCP connection and sometimes a helper like socat in the guest.
  • Overkill if you only have a simple, local, one‑VM setup and direct COM passthrough already works.

If you do try it, keep VirtualBox serial disabled in that VM so there is no confusion between /dev/ttyS0 and the TCP‑backed /dev/ttyV0.

5. Check for flow control and line settings mismatches

VirtualBox will happily pass through a port, but your Linux side might still fail silently if:

  • The guest uses hardware flow control (RTS/CTS) but the device expects none.
  • Baud or parity differs from what the Windows side was using.

On Linux guest:

stty -F /dev/ttyS0 115200 cs8 -cstopb -parenb -crtscts

Try with and without -crtscts, especially if your device is a simple USB‑UART with only TX/RX connected.

6. Make sure you are not confusing “present” with “working”

/dev/ttyS0 existing just means “guest sees a UART,” not “it is actually bridged to your hardware.”

Quick sanity check:

echo 'test123' | sudo tee /dev/ttyS0

Attach a loopback plug or connect RX to TX on the real device. If you do not see the bytes come back (using a separate terminal on the host or another system), the bridge is not functioning, and the issue is still on the VirtualBox / Windows side.

If you post your exact UART section from VBoxManage showvminfo, plus which of these routes you actually want (strict COM passthrough vs TCP bridge via Serial to Ethernet Connector), it becomes much easier to point at the last missing step.