You need remote access and RDP is the only client that works
You are sitting at a Windows laptop or a macOS machine and you need to access your Fedora desktop. Your company only allows RDP clients, or you just prefer the Microsoft Remote Desktop app because it handles clipboard sharing and drive redirection better than anything else. You install the xrdp package, start the service, and get a black screen or a connection timeout. The daemon is running, but the session never initializes. You are not doing anything wrong. The default Fedora desktop stack and the RDP protocol expect different things.
What xrdp actually does on Fedora
RDP is a Microsoft protocol. Linux does not speak it natively. xrdp is a protocol translator. It listens on port 3389, accepts the RDP handshake, and then spins up a local display server to render your desktop environment. Think of it like a universal power adapter. It takes the electrical standard your client expects and converts it into something your local hardware can actually use.
Fedora Workstation defaults to Wayland. xrdp historically expects Xorg. The mismatch causes silent failures. You also need to handle firewall rules, SELinux contexts, and session conflicts. If you are already logged in locally, the display manager will refuse to hand over the session to a remote user. The daemon will sit idle, waiting for a clean slate.
Run journalctl -xeu xrdp before you guess. Read the actual error before guessing.
Install and configure the daemon
The installation pulls the daemon, the session manager, and the required Xorg dependencies. Fedora packages these separately so you can run the server without pulling in a full desktop stack if you only need remote access to a headless machine.
Here is how to install the package and register the services with systemd.
sudo dnf install xrdp -y
# WHY: pulls the daemon, the session manager, and the required Xorg dependencies
sudo systemctl enable --now xrdp
# WHY: starts the service immediately and registers it for boot
sudo systemctl enable --now xrdp-sesman
# WHY: the session manager handles authentication and desktop spawning
The firewall blocks inbound connections by default. You need to open port 3389 in the persistent configuration and reload the runtime tables. Fedora's firewall daemon tracks persistent and runtime states separately. If you skip the reload, the rule exists on disk but the kernel netfilter tables ignore it.
Here is how to open the port and apply the change immediately.
sudo firewall-cmd --permanent --add-service=xrdp
# WHY: opens port 3389/tcp in the persistent firewall configuration
sudo firewall-cmd --reload
# WHY: applies the new rule to the running kernel netfilter tables
The default configuration lives in /etc/xrdp/xrdp.ini. You rarely need to touch it. The port is already set to 3389 and the security layer is configured for TLS encryption by default. If you change the port, update the firewall rule to match. Never edit files in /usr/lib/xrdp/. Those ship with the package and get overwritten on the next update. Edit /etc/ only.
Here is how to verify the daemon is listening on the correct port.
sudo ss -tlnp | grep 3389
# WHY: confirms the kernel socket is bound and waiting for connections
You should see xrdp listed next to 0.0.0.0:3389 or *:3389. If the line is missing, the service failed to start. Check the logs before restarting.
Restart the service after any config change. Trust the package manager. Manual file edits drift, snapshots stay.
Verify the connection
Open your RDP client and enter the IP address of your Fedora machine. Leave the port blank. RDP clients default to 3389. Enter your Fedora username and password. The first connection will take a few seconds while xrdp-sesman authenticates you and spins up the Xorg session.
If you are using the Microsoft Remote Desktop app on macOS or Windows, you will see a login screen that looks slightly different from your local GDM screen. This is normal. xrdp uses its own authentication prompt. After you log in, you will see a dropdown menu asking which session type to launch. Select Xorg. Do not select Xvnc unless you specifically want a virtual framebuffer without hardware acceleration.
Here is how to check the active session after you connect.
who
# WHY: lists all logged-in users and their associated pseudo-terminals
You should see your username attached to pts/0 or pts/1. The local console session remains untouched. If you see multiple entries for the same user, you have a session conflict. Log out of the remote session before opening another one.
Check the journal for session startup messages. Run journalctl -xeu xrdp-sesman to see authentication results and display server handoffs.
Common pitfalls and what the error looks like
The black screen is the most common symptom. It usually means xrdp started the X server but the desktop environment failed to load. This happens when your local user is already logged in on the physical machine. The X server cannot bind to the same display number twice. Log out locally, then connect remotely.
Another frequent issue is the Connection closed by foreign host message in your RDP client. This points to an authentication failure or a missing PAM module. Check the session manager log for the exact failure reason.
[ERROR] Xorg session failed to start
[ERROR] starting Xorg session on display 10
[ERROR] X server for display 10 startup timeout
The timeout means the X server process died before it could hand control back to xrdp. This almost always traces back to a missing driver or a Wayland/Xorg conflict. Switch your local GDM session to Xorg before connecting. You can do this by clicking the gear icon at the GDM login screen and selecting GNOME on Xorg.
SELinux denials also block remote sessions. Fedora enables SELinux in enforcing mode by default. The xrdp package ships with the correct policy modules, but custom firewall rules or third-party desktop environments can trigger alerts. Read the one-line summary in journalctl -t setroubleshoot before disabling SELinux. The audit log will tell you exactly which process was denied access to which file.
Disable SELinux only as a last resort. Re-enable it immediately after troubleshooting.
When to use xrdp versus other remote tools
Use xrdp when you need broad client compatibility and your users already have Microsoft Remote Desktop or a standard RDP client installed. Use TigerVNC when you want a lightweight, protocol-agnostic solution that works well over high-latency networks. Use SSH X11 forwarding when you only need to run individual GUI applications and want all traffic encrypted through an existing SSH tunnel. Use native Wayland remote protocols like PipeWire or Waypipe when you are running a fully Wayland-compliant stack and need zero-copy screen sharing. Stay on xrdp if you need drive redirection and clipboard synchronization out of the box.
RDP traffic is unencrypted by default on older clients. Tunnel it through SSH if you are connecting over an untrusted network. Run ssh -L 3389:localhost:3389 user@fedora-host and point your RDP client to localhost:3389. The tunnel handles encryption. The remote daemon handles the desktop.
Snapshot the system before the upgrade. Future-you will thank you.