nblomquist

Thanks!

I know AI can be troublesome with a lot of this. But I don't know if I would have found this without your help and its help.

It was just super frustrating to not be able to paste into applications if RDP was running with a Linux session inside!

Again, thanks!

I confirmed a working server-side workaround.

Debian 13/XFCE 4.20 runs `xfsettingsd`. It immediately requests every advertised image format, including `image/bmp`, which causes xrdp to request CF_DIB from RDM and triggers the clipboard round trip.

Disable only that clipboard component while leaving the rest of `xfsettingsd` running:

XFSETTINGSD_NO_CLIPBOARD=1 xfsettingsd --replace --daemon

After applying this, the `image/bmp` requests stopped. I repeated the same macOS screenshot test and pasted into Slack locally; it completed immediately without hanging.

To make this permanent, XFCE autostart entry can be overridden per user so that it runs:

env XFSETTINGSD_NO_CLIPBOARD=1 xfsettingsd

This is an effective workaround, although RDM should still handle failed DIB/TIFF conversion without leaving an unfulfilled pasteboard promise or blocking local applications.

I traced the XRDP session further.

Server: Debian 13, xrdp 0.10.1-3.1+deb13u1, XFCE.

A bpftrace trace of xrdp-chansrv’s X11 events shows the immediate request comes from `xfsettingsd` (PID 1582), not xrdp retrieving data merely because RDM announced CF_DIB.

`xfsettingsd` requests `TARGETS`, then `image/bmp` (plus PNG/JPEG/GIF). Its `image/bmp` request causes xrdp to send `CB_FORMAT_DATA_REQUEST(CF_DIB)` to RDM. `xfdesktop` only requested `TARGETS`.

So there is a concrete XFCE-side trigger for the immediate bitmap request. However, RDM should still avoid replacing the original local image with an unfulfillable TIFF promise or blocking local paste consumers if conversion fails.

I am going to see if I can disable `xfsettingsd` or turn off something over here to workaround it.

sent requested logs.

I did notice that it may be related to connecting to XRDP (Linux, Debian 13, XFCE) instead of just a regular windows 11.

Environment:

• RDM for macOS 2026.2.3.1

• macOS 26.5.2 (25F84), Apple Silicon

• Embedded RDP session

• Spotlight “Results from Clipboard” disabled

Summary:

With an embedded RDP session active, taking a local screenshot using Control+Command+Shift+4 causes RDM to replace the valid PNG on the macOS clipboard with promised Windows image formats. When a local application requests the advertised TIFF, RDM fails in PasteboardCliprdr.ToTiff() and never fulfills the clipboard promise.

The receiving application then hangs through repeated 60-second timeouts. This affects Slack, Chrome/Jira, Paintbrush and other Mac applications. It reproduces with Maccy or ClipBook and sometimes with no clipboard manager running.

Steps to reproduce:

1. Open an embedded RDP session in RDM.

2. On the local Mac, press Control+Command+Shift+4 and select an area.

3. Paste into a local application such as Slack.

4. The receiving application hangs or beachballs.

5. If allowed to time out, Slack may show image.png with a “not the right format” error.

Expected:

The local screenshot should paste normally. RDM should not replace it with an image representation it cannot render.

Diagnostic findings:

The unified macOS pasteboard log captures the complete failure:

• screencapture writes a 168,832-byte public.png.

• RDM successfully reads all 168,832 bytes.

• About 330 ms later, RDM becomes the new clipboard owner.

• RDM replaces the PNG with promised formats:

com.devolutions.rdp.cf-metafilepict

com.devolutions.rdp.cf-dib

com.devolutions.rdp.cf-dibv5

• public.tiffSlack requests public.tiff.

• pboard asks RDM to fulfill the promise.

• RDM throws:

Could not initialize an instance of the type

'AppKit.NSBitmapImageRep': the native 'initWithData:' method returned nil.

at AppKit.NSBitmapImageRep..ctor(NSData data)

at Devolutions.Rdp.Native.PasteboardCliprdr.ToTiff(...)

at Devolutions.Rdp.Native.PasteboardCliprdr.Provider_OnRenderClipboard(...)

at Devolutions.Rdp.Native.PasteboardItemProvider.ProvideDataForType(...)

RDM does not fulfill the promise. Slack times out after 60 seconds and retries several times, remaining blocked for approximately four minutes.

A Slack process sample confirms its main thread is blocked in:

NSImage initWithPasteboard

NSPasteboard _dataForType

CFPasteboardCopyData

mach_msg2_trapA simultaneous pboard sample shows pboard idle while waiting for the promised-data provider. The RDM sample shows its application and FreeRDP threads otherwise responsive. The failure occurs specifically in RDM’s macOS clipboard image conversion.

Scope:

• Multiple unrelated receiving applications are affected.

• Maccy and ClipBook can increase the frequency but are not required.

• Disabling Spotlight clipboard results does not help.

• Disabling RDP clipboard redirection or disconnecting RDM avoids the problem.

• Saving the screenshot to a file and dragging it into the application also works.

Related fixes:

RDM Mac 2026.1.12.2, released May 20, claimed improved macOS clipboard-history support to avoid RDP session hangs. A related forum report was marked Resolved/Implemented, although Devolutions later said the original changes addressed symptoms rather than the root cause:

• RDM macOS clipboard freeze report

• RDM Mac release notes

RDM 2026.2.2.1 also claimed to fix hangs when copying RDP text with a third-party clipboard manager:

• 2026.2.2.1 announcement

This case is different because it involves a local macOS PNG, affects local receiving applications and can occur without a clipboard manager. The logs point directly to Devolutions.Rdp.Native.PasteboardCliprdr.ToTiff().

2025.13.3 seems to fix the issue. Thanks for the quick response.

I am also unable to use RDP on 2025.13.2. Dropping back one version fixes it.

I will attempt to get a log file or something after work.

Just in case other stumble upon this post like I did.

I found that the last working version that showed the mouse cursor changing for resizing, hyperlinks, etc was 2023.3.13.4.

The interesting thing about this is that between 2023.3.13.4 and 2024.1.5.1 the dmg file size went down by roughly 50mb.

Hopefully this helps someone else.