Version
7.2.6
Host OS Type
Windows
Host OS name + version
Windows 11 (10.0.26200.9106), VirtualBox 7.2.6 r172322 win.amd64
Host Architecture
x86
Guest OS Type
Linux
Guest Architecture
x86
Guest OS name + version
Ubuntu 24.04.4 LTS, kernel 6.17.0-40-generic, MATE, X11 (not Wayland)
Component
Guest Additions/Shared Clipboard
What happened?
Disclaimer: Claude Opus was used to diagnose this problem and help write the report. It was a real issue though and I've worked around it with a watchdog
-- Alex
Summary
On a Linux/X11 guest, VBoxClient --clipboard intermittently stops receiving or acting on XFixes selection-owner notifications. From that moment it never again queries or reports X11 clipboard formats, so the host retains a stale format offer and every guest→host paste fails. Host→guest continues to work.
The process stays alive and apparently healthy — its X11 connection remains ESTABLISHED, its HGCM thread stays connected, and nothing is logged at the moment detection dies. Killing and restarting VBoxClient --clipboard restores normal operation immediately, until the next occurrence.
Observed roughly three times in one working day, at intervals from ~30 minutes to a few hours. No user action correlates with onset so far.
Not a version-mismatch issue: host and Guest Additions are the same Oracle build, 7.2.6 r172322, on both sides.
Both sides are Oracle's own binaries. Ubuntu's repackaged virtualbox-guest-{utils,x11} 7.0.16-dfsg packages were removed and pinned before 7.2.6 was installed, so no distribution-patched code is involved. The same symptom did also occur under those 7.0.16-dfsg packages, so it is not a 7.2.6 regression — but everything reported below was captured on the Oracle 7.2.6 build.
Evidence
Guest log, VBoxClient --clipboard -v -v -v -l (timestamps UTC). The service starts at 12:42:53 and works normally — two clipboard copies at 12:43:26 and 12:44:02 are detected and reported:
12:42:53.531570 shcl Shared Clipboard: Initializing X11 clipboard (regular mode)
12:42:53.544890 shcl Shared Clipboard: X11 event thread started
12:42:53.548745 shcl Shared Clipboard: Guest features: 0x3 - Host features: 0x3
12:43:26.358802 SHCLX11 Shared Clipboard: Querying X11 formats ...
12:43:26.359217 SHCLX11 Shared Clipboard: 4 X11 formats were found
12:43:26.366049 SHCLX11 Shared Clipboard: Reporting X11 format 'UTF8_STRING'
12:43:26.366099 SHCLX11 Shared Clipboard: Reporting X11 format 'STRING'
12:44:02.336374 SHCLX11 Shared Clipboard: Querying X11 formats ...
12:44:02.336542 SHCLX11 Shared Clipboard: Reporting X11 format 'UTF8_STRING'
After 12:44:02 there is not a single further Querying X11 formats line, despite several clipboard copies in the guest. Nothing at all is logged to mark the transition — detection simply stops.
The next log entries are the failed host paste attempts (12:51 and 12:59):
12:51:31.287692 SHCLX11 Shared Clipboard: Reading X11 clipboard data completed with VERR_SHCLPB_NO_DATA
12:51:31.288468 shcl Shared Clipboard: Waiting for event 2311391890 failed, rc=VERR_SHCLPB_EVENT_FAILED
12:51:31.293392 SHCLX11 Shared Clipboard: Reading X11 clipboard data completed with VERR_TRY_AGAIN
12:51:31.293662 shcl Shared Clipboard: Waiting for event 2311391891 failed, rc=VERR_SHCLPB_EVENT_FAILED
12:59:39.493266 SHCLX11 Shared Clipboard: Reading X11 clipboard data completed with VERR_TRY_AGAIN
12:59:39.493578 shcl Shared Clipboard: Waiting for event 2311391892 failed, rc=VERR_SHCLPB_EVENT_FAILED
12:59:40.525740 SHCLX11 Shared Clipboard: Reading X11 clipboard data completed with VERR_TRY_AGAIN
12:59:40.526547 shcl Shared Clipboard: Waiting for event 2311391893 failed, rc=VERR_SHCLPB_EVENT_FAILED
12:59:45.492561 SHCLX11 Shared Clipboard: Reading X11 clipboard data completed with VERR_TRY_AGAIN
12:59:45.493018 shcl Shared Clipboard: Waiting for event 2311391894 failed, rc=VERR_SHCLPB_EVENT_FAILED
So the host request does arrive; the guest cannot satisfy it, because the format it advertised belongs to a selection owner that has long since changed.
Direct confirmation that only VBoxClient stops noticing
While wedged, a test client took ownership of the CLIPBOARD selection and recorded every client that asked it for TARGETS:
[ 15.1 ms] asked for TARGETS pid=3182 snapd-desktop-integration
[ 16.7 ms] asked for TARGETS pid=3708 mate-terminal
[ 17.8 ms] asked for TARGETS pid=2572 caja
=> VBoxClient never asked.
Three unrelated X11 clients were notified within 18 ms. VBoxClient was not. The identical test against a healthy instance shows VBoxClient asking at ~15–25 ms (identifiable as the requestor with no _NET_WM_PID; confirmed by watching its X client resource base disappear when the service is stopped).
The guest-side X11 clipboard is entirely healthy while wedged
The current selection owner answered normally throughout:
TARGETS: OK in 20.8 ms, 5 items
UTF8_STRING: OK in 20.8 ms, 71 items
Detection mechanism
libXfixes.so.3 is mapped into the process and the binary resolves XFixesSelectSelectionInput via dlsym (the X libraries are dlopened, so ldd shows none of them — see /proc//maps). The failure is therefore consistent with the XFixes selection-notify registration or its dispatch being lost, while the rest of the service continues to function.
backtraces.txt
journal.txt
summary.txt
vboxclient-clipboard.log
How can we reproduce this?
I just have to wait for the clipboard to stop working. It normally takes ~1hour.
Did you upload all of your necessary log files, screenshots, etc.?
Version
7.2.6
Host OS Type
Windows
Host OS name + version
Windows 11 (10.0.26200.9106), VirtualBox 7.2.6 r172322 win.amd64
Host Architecture
x86
Guest OS Type
Linux
Guest Architecture
x86
Guest OS name + version
Ubuntu 24.04.4 LTS, kernel 6.17.0-40-generic, MATE, X11 (not Wayland)
Component
Guest Additions/Shared Clipboard
What happened?
Disclaimer: Claude Opus was used to diagnose this problem and help write the report. It was a real issue though and I've worked around it with a watchdog
-- Alex
Summary
On a Linux/X11 guest, VBoxClient --clipboard intermittently stops receiving or acting on XFixes selection-owner notifications. From that moment it never again queries or reports X11 clipboard formats, so the host retains a stale format offer and every guest→host paste fails. Host→guest continues to work.
The process stays alive and apparently healthy — its X11 connection remains ESTABLISHED, its HGCM thread stays connected, and nothing is logged at the moment detection dies. Killing and restarting VBoxClient --clipboard restores normal operation immediately, until the next occurrence.
Observed roughly three times in one working day, at intervals from ~30 minutes to a few hours. No user action correlates with onset so far.
Not a version-mismatch issue: host and Guest Additions are the same Oracle build, 7.2.6 r172322, on both sides.
Both sides are Oracle's own binaries. Ubuntu's repackaged virtualbox-guest-{utils,x11} 7.0.16-dfsg packages were removed and pinned before 7.2.6 was installed, so no distribution-patched code is involved. The same symptom did also occur under those 7.0.16-dfsg packages, so it is not a 7.2.6 regression — but everything reported below was captured on the Oracle 7.2.6 build.
Evidence
Guest log, VBoxClient --clipboard -v -v -v -l (timestamps UTC). The service starts at 12:42:53 and works normally — two clipboard copies at 12:43:26 and 12:44:02 are detected and reported:
12:42:53.531570 shcl Shared Clipboard: Initializing X11 clipboard (regular mode)
12:42:53.544890 shcl Shared Clipboard: X11 event thread started
12:42:53.548745 shcl Shared Clipboard: Guest features: 0x3 - Host features: 0x3
12:43:26.358802 SHCLX11 Shared Clipboard: Querying X11 formats ...
12:43:26.359217 SHCLX11 Shared Clipboard: 4 X11 formats were found
12:43:26.366049 SHCLX11 Shared Clipboard: Reporting X11 format 'UTF8_STRING'
12:43:26.366099 SHCLX11 Shared Clipboard: Reporting X11 format 'STRING'
12:44:02.336374 SHCLX11 Shared Clipboard: Querying X11 formats ...
12:44:02.336542 SHCLX11 Shared Clipboard: Reporting X11 format 'UTF8_STRING'
After 12:44:02 there is not a single further Querying X11 formats line, despite several clipboard copies in the guest. Nothing at all is logged to mark the transition — detection simply stops.
The next log entries are the failed host paste attempts (12:51 and 12:59):
12:51:31.287692 SHCLX11 Shared Clipboard: Reading X11 clipboard data completed with VERR_SHCLPB_NO_DATA
12:51:31.288468 shcl Shared Clipboard: Waiting for event 2311391890 failed, rc=VERR_SHCLPB_EVENT_FAILED
12:51:31.293392 SHCLX11 Shared Clipboard: Reading X11 clipboard data completed with VERR_TRY_AGAIN
12:51:31.293662 shcl Shared Clipboard: Waiting for event 2311391891 failed, rc=VERR_SHCLPB_EVENT_FAILED
12:59:39.493266 SHCLX11 Shared Clipboard: Reading X11 clipboard data completed with VERR_TRY_AGAIN
12:59:39.493578 shcl Shared Clipboard: Waiting for event 2311391892 failed, rc=VERR_SHCLPB_EVENT_FAILED
12:59:40.525740 SHCLX11 Shared Clipboard: Reading X11 clipboard data completed with VERR_TRY_AGAIN
12:59:40.526547 shcl Shared Clipboard: Waiting for event 2311391893 failed, rc=VERR_SHCLPB_EVENT_FAILED
12:59:45.492561 SHCLX11 Shared Clipboard: Reading X11 clipboard data completed with VERR_TRY_AGAIN
12:59:45.493018 shcl Shared Clipboard: Waiting for event 2311391894 failed, rc=VERR_SHCLPB_EVENT_FAILED
So the host request does arrive; the guest cannot satisfy it, because the format it advertised belongs to a selection owner that has long since changed.
Direct confirmation that only VBoxClient stops noticing
While wedged, a test client took ownership of the CLIPBOARD selection and recorded every client that asked it for TARGETS:
[ 15.1 ms] asked for TARGETS pid=3182 snapd-desktop-integration
[ 16.7 ms] asked for TARGETS pid=3708 mate-terminal
[ 17.8 ms] asked for TARGETS pid=2572 caja
=> VBoxClient never asked.
Three unrelated X11 clients were notified within 18 ms. VBoxClient was not. The identical test against a healthy instance shows VBoxClient asking at ~15–25 ms (identifiable as the requestor with no _NET_WM_PID; confirmed by watching its X client resource base disappear when the service is stopped).
The guest-side X11 clipboard is entirely healthy while wedged
The current selection owner answered normally throughout:
TARGETS: OK in 20.8 ms, 5 items
UTF8_STRING: OK in 20.8 ms, 71 items
Detection mechanism
libXfixes.so.3 is mapped into the process and the binary resolves XFixesSelectSelectionInput via dlsym (the X libraries are dlopened, so ldd shows none of them — see /proc//maps). The failure is therefore consistent with the XFixes selection-notify registration or its dispatch being lost, while the rest of the service continues to function.
backtraces.txt
journal.txt
summary.txt
vboxclient-clipboard.log
How can we reproduce this?
I just have to wait for the clipboard to stop working. It normally takes ~1hour.
Did you upload all of your necessary log files, screenshots, etc.?