Stop Ubuntu's Screen Lock from Killing Your Remote Desktop Sessions

If your Ubuntu screen-sharing connection drops after a period of inactivity and only recovers after you walk over to the machine and unlock it, the GNOME screen lock is the cause. The remote desktop service runs inside your user session and stops accepting connections while that session is locked. Disable the automatic lock, or explicitly allow remote access to a locked session, and the problem disappears.

Why the lock breaks screen sharing

Ubuntu's built-in Desktop Sharing is provided by gnome-remote-desktop, which runs inside your logged-in graphical session rather than as a system-wide service. When GNOME decides the session is idle — after the blank-screen delay, or when someone presses Super+L — it locks the session. In that locked state the listener on port 3389 (RDP) or 3390 (VNC) no longer accepts new connections, so your client times out or is refused. The machine is still powered on; only the session is locked. The moment someone unlocks it locally, the listener returns and remote access works again.

Confirm the lock is the culprit

Before changing settings, rule out networking and power issues:

• When a connection fails, test the port from another machine, for example nc -zv <ip-address> 3389. If the port refuses while the screen is locked but responds right after a local unlock, the lock is responsible.
• Check Settings → Power → Automatic Suspend. Actual suspension is a different problem requiring a "never suspend" setting or Wake-on-LAN.
• Verify the machine is on the network at the moment of failure — a dropped Wi-Fi link mimics the same symptom.

Fix 1: turn off the automatic screen lock

The simplest solution keeps manual locking available but stops GNOME from locking on its own. On the target machine, open Settings → Screen Lock (under Privacy or Screen, depending on the release) and switch off Automatic Screen Lock. Then set Screen Blank to Never under Settings → Power so the idle timer never starts in the first place.

The same settings from a terminal:

gsettings set org.gnome.desktop.screensaver lock-enabled false
gsettings set org.gnome.desktop.session idle-delay 0

Run these as the user who owns the desktop session — not with sudo — because they are stored in that user's dconf database.

Fix 2: block the lock screen entirely (lockdown mode)

If you want locking to be impossible under any circumstance, including a manual Super+L or the Lock entry in the system menu, use GNOME's lockdown flag:

gsettings set org.gnome.desktop.lockdown disable-lock-screen true

To check the current state:

gsettings get org.gnome.desktop.lockdown disable-lock-screen

To restore normal locking later:

gsettings reset org.gnome.desktop.lockdown disable-lock-screen

Fix 3: keep the lock but allow remote connections

Prefer keeping the lock yet still connecting remotely? The GNOME Shell extension Allow Locked Remote Desktop keeps the remote desktop listener alive while the session is locked, letting you connect and type your password through the remote session itself. Install it from the GNOME Extensions website on the machine you connect to, enable it with the Extensions or Extension Manager app, then reconnect. For headless or hard-to-reach machines this offers the best balance of convenience and security.

A middle path: unlock over SSH

If you keep SSH access enabled, you can unlock a locked session without walking over:

loginctl list-sessions
loginctl unlock-session <ID>

Identify your graphical session in the first command's output, then unlock it by ID. It works, but it is clumsy as a routine workflow — treat it as an emergency escape hatch rather than your primary method.

Prevention and security notes

• On machines in trusted rooms, disabling only the automatic lock is usually enough; manual locking stays available for when you step away.
• An always-unlocked desktop is a genuine risk where others can reach the keyboard. Favor the extension (Fix 3) or SSH unlocking in shared or physically accessible spaces.
• Protect the remote desktop itself with a strong password, and restrict port 3389/3390 with a firewall or VPN where possible.
• If you apply the gsettings changes remotely over SSH, reconnect once afterward so the service picks them up cleanly.

Frequently Asked Questions

Why does the connection work fine until the machine sits idle?

The idle timeout triggers GNOME's screen lock, and the remote desktop listener lives inside the user session. When the session locks, the listener stops accepting new connections until someone unlocks the machine locally.

Does disabling the lock screen create a security risk?

It can. Anyone with physical access reaches an unlocked desktop, and remote access is guarded only by your sharing password. Disable the automatic lock on machines in trusted spaces; use the extension approach where physical access is a concern.

I disabled the lock but connections still fail. What now?

Check that the machine is not suspending, test the port directly, and confirm the settings were applied to the correct user — running gsettings with sudo writes to root's database instead of yours.

What is the difference between lockdown mode and the extension?

The lockdown flag removes the lock screen completely, so manual locking stops working too. The extension keeps locking intact but permits remote desktop connections to attach to a locked session so you can unlock it remotely.

Do I need to reboot after changing these settings?

Usually not. The changes take effect for the running session; if remote access still misbehaves, log out and back in once to restart gnome-remote-desktop cleanly.

Can I keep the display blanking for power savings?

Often yes — the blank itself is not the problem, the lock that follows is. Try disabling only the automatic lock first and leave Screen Blank enabled; if connections still fail, set blanking to Never as well.