virtualbox.org

Don,t know how to fix this but instead of shutting down virtual machine just save the state of virtual machine and the resume again and things will be normal after that.No unsaved work will be lost.Works well for me

Same problem here, with Version 6.1.8 r137981 (Qt5.9.7),Leap 15.2 host running on Leap 15.2 on guest.
This never appear for me before.

You might want to try updating VirtualBox, as 6.1.8 is already becoming a bit 'dated', but I can't see anything in the Change Log that specifically relates to this problem with Linux Guests on Linux Hosts, See: https://www.virtualbox.org/wiki/Changelog

Same problem with virtualbox 6.1.12 and leap 12.1 kernel 4.12.14-lp151.28.52-default

I must say that when the problem arise, you have to move the mouse on each app windows then use the keyboard shortcut to leave each app then select the kickoff menu (on opensuse), select 'leave', select reboot.
In other words you select with the mouse, then replace the mouse click with the keyboard shortcut.

A workaround that has worked for me, specifically in the case where the mouse click stops working on all windows except the Desktop toolbar at left edge: I enter Alt-F2 and when the command box shows up, type "restart". After a few seconds, mouse clicks work again.

It seems to me like some app is grabbing mouse input for the whole desktop (which would not include the toolbar), and is forced to drop it when the desktop manager restarts, thus restoring it (same logic with log-out/in.

Given some other posts, I suspect dnd. So I just disabled bidirectional drag-and-drop (which I never use anyways), and killed the two /usr/bin/VBoxClient --draganddrop that were running. I'll see if the problem re-occurs, and next time I restart the VM I'll check if those processes are running (I'm hoping they are started only when bidirectional dnd is on).

Update: the vboxclient process still get started, even if DnD is disabled in the settings. I'm pretty sure the problem occurred even after I did the above, so I have yet to find a way to prevent it. But at least there are 2 workarounds: Alt-F2 then enter "restart" in the box that appears; or drag an item from host onto VM desktop.

This issue has been driving me nuts for some while as parts of the screen got unresponsible to mouse clicks. I had to move windows to other regions that were clickable. Killing the VBoxClient process works.

Same issue here with VirtualBox 6.1.22 and latest Kali Linux.

Killing the drag and drop process helps, but a bugfix would be great.

Hi all

sudenly I experienced the same problem.

Ubuntu 21.4
VirtualBox 6.1.22
Guest Windows 10 Pro
Extension pack activated

I never hab this problem before. Now when it happens,
- I see the cursor and can move it.
- Guest system react normally with keyboard.
- Can't click in guest system nor on vVirtualBox interface
- Drag&Drop and shared clipboard functionallities were deactivated in machine configuration
- Loging out and in on guest system don't change anything
- It happens only when guest system is in fullscreen mode

I hope this bug will be fixed.

I've had this problem with most versions of VirtualBox since around 5.16 on one computer.
Both host and guest are running Windows 10. Later versions of Windows 10 and VirtualBox are worse than earlier versions.

Interestingly enough on two other computers running Windows 10 host and exact same guest (copy of VM) this issue does not occur.

One quick workaround I found that works is to right click inside the guest and that seems to restore the left click functionality for a while.

I'm having the same issue.

I used to see this "click doesn't work problem" once in a while. I had Debian 10 (buster) and a decent amount of work could be done before the click stopped working and I had to save the vm state and start it again to gain control over the click. But some days ago I decided to go with the Debian 11 (bullseye) update and the click lost problem became annoying to the point that I no longer can continue working on the vm. I'm setting up a new virtual machine in a different program. I love Virtual Box but its impossible to work like this. This used to be a minor inconvenience but now it makes the virtual machine unusable.

I'm attaching the log of my Virtual Machine in a session where I started the machine a few minutes later got the problem, saved the state while turning it off, to start it again an gain control over the mouse click again. I hope this help solving the problem.

I am seeing this with a Linux host (fully updated Devuan and VirtualBox 6.2) and Windows 7 guest. Everything works well, I leave the guest to do something in Linux and after a variable time I lose the ability to click on anything with either mouse button or to scroll with the wheel. There is no way to get back to the guest at this time to see if the mouse continues to work there. The only solution is to change to another terminal alt ctrl F6 usually check for the pid of the virtual machine and kill it. I have never lost control of the mouse in the virtual machine only after I have moved to Linux. Then switching back again I have working mouse and an aborted virtual machine with any unsaved work lost. This is happening several times a day at the moment. I have seen this in the past with Windows 7 guest on Debian several years ago I don't remember the version of VirtualBox.

Taz in Austria wrote:The only solution is to change to another terminal alt ctrl F6 usually check for the pid of the virtual machine and kill it. I have never lost control of the mouse in the virtual machine only after I have moved to Linux. Then switching back again I have working mouse and an aborted virtual machine with any unsaved work lost.

I am seeing the same behaviour on Debian stable host, Debian unstable (and others) guests.

One better workaround might be (which works for me) to navigate to a host terminal window and there in the terminal list running vms with and then save the state (in my case something like): For me this reactivates mouse events on the host which makes me believe it indeed is a virtualbox problem. This will at least not force you to close down the VM and loose your work, but make you be able to keep the work in the VM.
It is still a pain in the ass, but a bit more tolerable.

To add some more info that might be useful -

Running two VMs - one Debian unstable, one Windows 10 -

Mouse got locked up as described in this thread, and it was enough to run the savestate on the Debian unstable one to get the mouse unlocked this time. Windows 10 still running minimized and everything works fine after the savestate on the unstable one.

Edit: And now after a while the mouse got locked again, and then I run savestate on the Windows VM, and the problem is fixed.

It seems that if you inadvertently hide the USB receiver from the 'computer-mouse' link for a short time, the link is lost and cannot be restored in a simple way other than a reboot.