GNOME Remote Desktop (GRD) is the preferred Smithflix remote desktop path for adam when using GNOME Remote Login over an SSH-tunneled RDP session. XRDP remains available on a separate port as the fallback path during validation and short-term soak.
This page documents the host-level GRD system service, the retained XRDP fallback, the SSH-tunneled access pattern, and the local helper used to inspect or reset GRD credentials.
gnome-remote-desktop.service/usr/libexec/gnome-remote-desktop-daemon --systemgnome-remote-desktop 46.3-0ubuntu1.2gdm.service/etc/gdm3/custom.conf because WaylandEnable=false is not set*:3389*:3391 via XRDPxrdp 0.9.24-42026-05-03: gnome-remote-desktop.service, gdm.service, and xrdp.service were all active/etc/gnome-remote-desktop/grd.conf/var/lib/gnome-remote-desktop/var/lib/gnome-remote-desktop/.local/share/gnome-remote-desktop/certificates/rdp-tls.key/var/lib/gnome-remote-desktop/.local/share/gnome-remote-desktop/certificates/rdp-tls.crt/etc/gdm3/custom.conf/etc/xrdp/xrdp.ini/home/adam/scripts/configure-gnome-remote-desktop.shlocalhost:3389 on the host for GRDlocalhost:3391 on the host for XRDP3389Example SSH tunnels from the Mac:
ssh -N -L 13389:127.0.0.1:3389 adam@smithflix
ssh -N -L 13391:127.0.0.1:3391 adam@smithflix
Use the first tunnel for the GNOME Remote Login profile and keep the second available as the rollback path during validation.
adam for client consistencyGRD_PASSWORD=... for one-shot scripted resetssudo bash /home/adam/scripts/configure-gnome-remote-desktop.sh --check
adam:sudo bash /home/adam/scripts/configure-gnome-remote-desktop.sh --apply
sudo GRD_PASSWORD='strong-password' bash /home/adam/scripts/configure-gnome-remote-desktop.sh --apply --username adam
sudo grdctl --system rdp clear-credentials
sudo grdctl --system rdp set-credentials adam 'strong-password'
sudo systemctl restart gnome-remote-desktop.service
sudo timeout 10s grdctl --system status
The local host checks confirm only that the services are up and listening. The client workflow still needs validation from the Mac using Windows App.
Recommended validation order:
127.0.0.1:13389.adam credential.127.0.0.1:13391 as rollback.Acceptance criteria:
journalctl -u gnome-remote-desktop.service -n 50 --no-pager
ss -ltnp | grep -E ':(3389|3391)\b'
2026-05-03, GRD logs showed prior authentication and negotiation failures including Could not find user in SAM database, which is the primary reason to re-check or reset the stored GRD credentials when the client login fails even though the service is listening2026-05-03, the failure pattern changed to a repeatable redirection disconnect:[RDP] Sending server redirection
[ERROR][com.freerdp.core.peer] - [rdp_set_error_info]: ERRINFO_LOGOFF_BY_USER [0x0001000C]
[RDP] Network or intentional disconnect, stopping session
This confirms the client reaches GRD and gets through the initial server path; the break is during the GNOME Remote Login handover/redirection stage.
GNOME Remote Login depends on RDP ServerRedirection. SUSE's GNOME headless-session write-up explains that the GRD system daemon redirects the RDP client to session-specific GRD daemons using a routing token, one-time credentials, and a certificate. The same write-up recommends setting use redirection server name:i:1 in .rdp files because the default Microsoft client behavior can mishandle the handover.
Online reports matching the Smithflix symptom:
Remote logins from Window, Can't Login from MacOS | Gnome | RDP: reports the same Sending server redirection plus ERRINFO_LOGOFF_BY_USER [0x0001000C] log pattern when trying to connect from macOS.CentOS 10 - Blank screen when connecting to Gnome Remote Desktop: a macOS Windows App user reports the workaround of exporting the profile, changing use redirection server name:i:0 to use redirection server name:i:1, and re-importing the profile.Ubuntu 24.04 Remote Login connects to black screen: shows the same Sending server redirection and ERRINFO_LOGOFF_BY_USER pattern, though that report later points at a separate PipeWire/Wayland issue.RDP Handover Regression in FreeRDP 3.5.1-0ubuntu1.4: describes a GNOME Remote Login handover failure where initial NLA succeeds, the server sends the redirection/handover token, and the connection is immediately severed. Smithflix currently has libfreerdp3-3 3.5.1+dfsg1-0ubuntu1.5, so this needs watching before assuming the issue is only the macOS client.RDP to Ubuntu from the Windows App on macOS: describes Windows App on macOS failing until the .rdp file was changed to use redirection server name:i:1.Current next trial for Smithflix is the .rdp profile change in Windows App on macOS. If that fails, test with xfreerdp or another client known to follow GRD redirection so the client and Ubuntu FreeRDP-server-package possibilities can be separated.
/var/lib/gnome-remote-desktop becomes corrupt, replace it only when a concrete TLS trust or handshake issue is observed3389 but the client login fails, reset GRD credentials first; do not assume Linux account credentials automatically applySending server redirection followed by ERRINFO_LOGOFF_BY_USER, treat it as a handover/redirection failure rather than a basic tunnel, listener, or credential failureuse redirection server name:i:1, delete the old profile, and re-import the edited profile3391 while troubleshooting rather than changing network exposure2026-05-032026-05-032026-05-03