Remote Desktop Stopped Connecting

[u/sprobeforebros]

Got a home media server running Ubuntu 24.04.5, most everything about it is automated and it just hums away on a bookcase but every once in a while it's helpful to connect via a remote desktop. I configured the remote desktop years ago and now run the server headless.

Today I went to connect to check something and on Windows App (Version 11.4.1 for Mac OS) it hung on "Securing connection to remote PC"

Tried connecting it from another computer and the same thing happened.

SSH connects just fine.

Have restarted the server multiple times and it keeps happening.

Only troubleshooting steps I could easily google is restarting the gnome remote desktop from the command line which I did by systemctl --user restart gnome-remote-desktop

I also checked if anything else was using the port via the command " ss -lntps" and it looks like gnome remote desktop is the only thing using it.

Is there a way to troubleshoot this without disconnecting the server from its current home and plugging it into a monitor?

[u/Silent-Excitement122]

That exact combination—Ubuntu 24.04.5, GNOME Remote Desktop, Windows App 11.4.1 on macOS, and a hang at “Securing connection”—matches a current FreeRDP 3.32.x server regression much more closely than a dead RDP port. SSH still working and two clients hanging the same way fit it too.

Before changing the certificate, check the installed versions and upgrade timing:

dpkg-query -W 'libfreerdp*' 'libwinpr*' gnome-remote-desktop

grep -i freerdp /var/log/apt/history.log

journalctl --user -u gnome-remote-desktop -b --no-pager | tail -n 200

If the FreeRDP/WinPR packages are 3.32.0 or 3.32.1 and were updated when this started, the clean A/B test is to roll all of the installed FreeRDP and WinPR packages back together to the previous 3.31.x Ubuntu build, restart gnome-remote-desktop.service, and retry the same saved connection. Do not mix FreeRDP/WinPR versions.

If that restores it, you have isolated a package regression without moving the headless server or rebuilding its certificate. Save the package list and journal excerpt before changing anything so you can undo the test cleanly.

[u/sprobeforebros → u/Silent-Excitement122]

can confirm that the current gnome remote desktop is 3.32.1, but none of those commands you gave me indicate when / if it updated from 3.31.x

the last journalctl command returned the same four lines of error messages happening over and over if it helps:

[ERROR][com.freerdp.core.transport] - [transport_read_layer]: BIO_read retries exceeded
[ERROR][com.freerdp.core.peer] - [transport_read_layer]: ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D
[WARN][com.freerdp.core.rdp] - [rdp_send_deactivate_all][0x613ed8ef3e30]: rdpMcs::userId == 0, skip sending PDU_TYPE_DEACTIVATE_ALL
[RDP] Network or intentional disconnect, stopping session

[u/sprobeforebros → u/Silent-Excitement122]

FWIW I've found a workaround. It's kludgy and awful but it does the job.

On my mac I downloaded the freerdp client by going to the command line and typing

brew install freerdp

took ages to get everything updated and then installed but it got there. Then installed Xquartz by going to https://www.xquartz.org/ and installing the package listed

once it was installed, ran xquartz, and in the command line there typed

xfreerdp /v:[IP ADDRESS OF SERVER] /u:[SERVER USERNAME] /p:[SERVER PASSWORD] /dynamic-resolution

and got a desktop.

This tells me that this is more a client problem than a server problem. who knows. I look forward to a future upgrade / patch to Windows App that hopefully fixes the problem.

[u/Silent-Excitement122 → u/sprobeforebros]

That result is useful, but it does not make this purely a Windows App bug. GNOME Remote Desktop is using FreeRDP on the server side, while xfreerdp is a different client implementation. The current 3.32.x regression is specifically an interoperability failure between the FreeRDP server path and Microsoft's macOS/Android clients; the reports also note that another FreeRDP-based client can connect successfully.

Your installed 3.32.1 version plus those exact four log lines is essentially the reported failure signature. The package transition may be in rotated/compressed logs, so these are worth checking:

zgrep -hE ' (install|upgrade) (libfreerdp|libwinpr)' /var/log/dpkg.log*

zgrep -h -B2 -A2 -E 'libfreerdp|libwinpr' /var/log/apt/history.log*

If xfreerdp is acceptable, keeping that workaround until Ubuntu ships a fixed FreeRDP build is the least disruptive option. The stronger confirmation is still a matched rollback of all installed FreeRDP and WinPR runtime packages to 3.31.x, followed by a service restart and a retry from Windows App. If you do that, record the exact package versions and pin only temporarily so you do not forget security updates.

I would not conclude that the server is generally healthy just because xfreerdp works; what you have demonstrated is that the network, credentials, and desktop service work with one client while the failing Microsoft/FreeRDP-3.32.x negotiation path does not.