Why am I seeing a black screen on Chrome Remote Desktop in Ubuntu?

Chrome RDP
1

Whenever I try to use Chrome Remote Desktop to connect to my Ubuntu machine, all I see is a black screen instead of my desktop. It was working before, but now I can’t access anything remotely. I really need to get this fixed as I rely on remote access for my work. Any ideas on what could be causing this or how to solve it?

2

The Infamous Chrome Remote Desktop Black Screen (Linux Edition)

So here’s the deal: if you’re banging your head against the desk because Chrome Remote Desktop just gives you a big ol’ void of darkness on your Linux box, know this—you are definitely not alone. This isn’t some rare bug, it’s more like a rite of passage for anyone attempting remote access with Linux.

What Actually Happens (Or Rather, What Doesn’t)

Picture this: you log in, connection seems solid, but nada. No desktop, no widgets, nothing but the digital equivalent of staring into the abyss. CRD does this thing where it tries to spin up an entirely new X session instead of just piggybacking on whatever’s running. Even better? On desktops like GNOME, it often can’t even get that far—no environment loads, so you’re basically watching a live feed of your own disappointment.

Here’s what usually screws things up:

  • Brand new X session (so your running stuff isn’t even accessible)
  • Failing outright to launch a desktop (with GNOME, this basically becomes a game of “how black can my screen get?”)

Quick List: How I Stopped Losing My Mind

  1. Ditch GNOME, Embrace XFCE

    • GNOME’s like that fancy coffee machine at work that never works when you need it. XFCE? It just gets the job done, no frills.

    • Quick-and-dirty steps that finally did it for me:

      sudo apt install xfce4 xfce4-goodies
echo 'startxfce4' > ~/.chrome-remote-desktop-session

    • Make sure you reboot CRD or the machine. Repeat after me: “I will never doubt XFCE again.”

  2. Only Google Chrome Will Do

    • This isn’t the time to get creative. Chromium sometimes just can’t hack it. Official Chrome is a must.

  3. Let X Trust You (xhost Solution)

    • If you’re connecting, but CRD is just showing you blackness, try this classic move in your terminal:
      xhost +
    • Sure, it opens up the display server a bit (don’t do this on an exposed server!), but it lets CRD talk to the display.

  4. Config Folders Exist For a Reason

    • Sometimes CRD needs its config setup right. Knock this out:
      mkdir -p ~/.config/chrome-remote-desktop

  5. Going Nuclear: Editing Startup Scripts

    • If you’re desperate, dig into /opt/google/chrome-remote-desktop/chrome-remote-desktop and:
      • Hardcode the display number you want.
      • Stop it from spinning up fresh X sessions each time.
      • Make it reuse your session instead.
    • This is more of a hack than a fix, and can break with updates. Proceed if you love living dangerously.

TL;DR: Here’s The Magic Formula

  1. Swap out GNOME for XFCE (seriously, just give up on GNOME for this).
  2. Make absolutely certain you’re running real-deal Google Chrome.
  3. Kill and restart Chrome Remote Desktop (or the box, if you’re impatient).

If you’re still seeing the abyss after this, it’s almost guaranteed the problem is with display/session management, not your connection or file permissions. Trust me, I’ve seen black more times than Batman at midnight.

Got another way out of the void? Drop it below, maybe you’ll save yet another soul from the remote desktop blues!

2 Likes
3

Yup, black screen on Chrome Remote Desktop with Ubuntu is basically the Linux version of “did you turn it off and on again?” I see @mikeappsreviewer is preaching the XFCE gospel, and while I admit GNOME can be a pain here, switching desktop environments isn’t always the nuclear fix I want to take. Sometimes you don’t want to abandon the look and feel/settings you’ve built up in GNOME just for one stubborn app. Call me stubborn.

Let me add a few alternatives to the XFCE route, especially if you’re not ready to completely change your desktop environment:

  1. Are you logged in locally?: CRD doesn’t always play nice if you’re already logged into the console session (physically at the computer). Log out locally, then try connecting via CRD—sometimes this magically “fixes” the black screen, because the session manager and X server get confused who’s supposed to be in charge.

  2. Check for Wayland Misery: Starting with Ubuntu 22.04+, GNOME often defaults to Wayland instead of Xorg. Chrome Remote Desktop doesn’t handle Wayland sessions! You gotta sign out and choose ‘GNOME on Xorg’ or ‘Ubuntu on Xorg’ at the login screen.

  3. Screen Lockers Gone Wild: If you use custom screen lockers or have a crazy combination of GNOME extensions, sometimes those interact badly with virtual/display sessions and just result in… infinite darkness. Try disabling them if you can.

  4. .Xauthority/Permissions: I know, everyone ignores this, but check your home directory ownership and permissions—CRD sometimes freaks out if ~/.Xauthority is locked by another user or has root ownership due to past sudo mistakes:

    sudo chown YOURUSERNAME:YOURUSERNAME ~/.Xauthority

    Replace YOURUSERNAME with your user.

  5. Try the ‘Remote Support’ Mode: Instead of accessing via your “My Computers” list, generate a support code and connect from another machine using that, sometimes that spawns an attachable session where a regular connection just black screens.

  6. System Updates and CRD Versions: Ubuntu updates (like a random GDM update or graphics driver tweak) can break stuff outta nowhere. Make sure Google Chrome Remote Desktop is up to date, but sometimes, rolling back a system update (esp. anything windowing/session manager related) actually helps.

  7. Stop CRD From Starting its own Session: This one’s risky, but instead of editing the startup scripts as @mikeappsreviewer suggested, try running /opt/google/chrome-remote-desktop/chrome-remote-desktop --stop and then use export DISPLAY=:0 with your main user to see if CRD starts using your actual desktop session.

Overrides and workarounds aside, Chrome Remote Desktop was designed for people who (let’s be real) run Chrome on Windows/Mac and rarely deal with Xorg/Wayland weirdness, so half of what we do on Linux is “unsupported” anyway. If it was working before and suddenly black-screened, there’s a good chance it’s Wayland, local user lock, or a permissions issue. I don’t personally switch to XFCE unless I’m out of other options; feels like treating a broken taillight by replacing the whole car.

If all else fails and you’ve hit the black void, consider alternative remote desktop tools like xrdp or NoMachine, especially for GNOME/Wayland users. There’s no shame in switching horses mid-race if one keeps taking you off a cliff!

4

So, @mikeappsreviewer pretty much nailed the whole GNOME vs XFCE saga (hilarious, btw), but here’s another angle that got me out of the “live feed of my own disappointment,” as they put it. Not everyone wants to nuke their comfy GNOME install just for Chrome Remote Desktop, and sometimes yes, it DOES work—it just stops working randomly and makes you question reality.

Here’s what actually worked for me when this fungus crept in:

Check if your User Session Is Actually Active

Sometimes remote desktop is trying to open a desktop environment, but your user isn’t logged in or the screen is “locked.” Ubuntu with GDM is notorious for this. Try this:

  • SSH into your machine or use a local keyboard.
  • Make sure your session is “active”. Just log in directly if you can, or toggle your screen lock on/off.
  • Restart the chrome-remote-desktop service:
    sudo systemctl restart chrome-remote-desktop@$USER
  • Try connecting again.

Wayland: The Secret Villain

If you’re running Ubuntu 22.04 or newer, bet you’re on Wayland by default. Chrome Remote Desktop simply does NOT get along with Wayland. You have to log out, hit the little gear at the login prompt, and pick “Ubuntu on Xorg” instead. No XFCE exorcism needed.

  • Didn’t see that in @mikeappsreviewer’s crusade: The GNOME + Xorg combo can actually be fine as long as you get Wayland out of the picture.

Reinstall CRD

Corrupt config files and weird permissions cause black screens too. Put on your rubber gloves and blow away the configs:

sudo apt-get remove chrome-remote-desktop
rm -rf ~/.config/chrome-remote-desktop
sudo apt-get install chrome-remote-desktop

Register the computer again via the browser as if it’s the first time. If you’re not getting the registration prompt, use Google Chrome (not Chromium)—yeah, I’ll agree with that part at least.

Permissions Shenanigans

Sometimes, it’s literally some glitched ~/.Xauthority permissions or missing file. Check ownership (should match your user).

Don’t Use xhost + Unless You Love Chaos

Sorry, but “xhost +” is like leaving your house with all your doors open. If you must, do:

xhost +SI:localuser:chrome-remote-desktop

That way only CRD gets in, not the whole internet.

Recap

  1. Make sure you’re on Xorg, not Wayland.
  2. Don’t bother switching to XFCE unless you’re out of options—GNOME can work w/proper Xorg.
  3. Check your session is active & not locked.
  4. Reinstall CRD and nuke the configs.
  5. Only escalate to major surgery (changing DE or hacking scripts) if the above fail.

Crazy how the simplest thing (like the wrong display server) breaks everything. And yes, sometimes even with all this, Chrome Remote Desktop just throws a tantrum. If that happens, I use alternative tools like xrdp, NoMachine, or even VNC. CRD is great—when it works. Otherwise, it’s the pretty wallpaper to your remote-access migraine.

5

Alright, black screen woes with Chrome Remote Desktop (CRD)—let’s slice through the noise. Everyone evangelizes XFCE and the death of Wayland, but there’s more than one way out of this pit. Quick-fire insights:

Pros for sticking with CRD: If it works, buttery-smooth integration in the Chrome ecosystem and ultra-convenient for cross-platform scenarios.
Cons: Locking you into Xorg (Wayland isn’t your friend, as previously screamed), a weird obsession with launching new sessions, barely-documented bugs, and awkward multi-monitor support.

There’s some solid advice above about desktop switching (can confirm: XFCE is boring but bulletproof for remote work), but nuking GNOME or your whole config isn’t always necessary. Before the full desktop apocalypse, check these:

  • Sometimes it’s as simple as re-enabling remote desktop access in Chrome (yep, CRD disables itself randomly after updates; check).
  • Audio devices missing in Ubuntu can trigger a black screen on CRD. Run pavucontrol and check I/O device status.
  • Double-check for headless GPU quirks. Machines with no monitor plugged in can blank the X display. Plug in a dummy HDMI dongle or use xrandr to force a screen:
    xrandr --output HDMI-1 --auto
    (Replace HDMI-1 with your actual output.)

If you’re done with CRD’s tantrums, give NoMachine or even TigerVNC a whirl. NoMachine, for example, generally laughs in the face of GNOME/Wayland drama (plus it handles clipboard and file transfer better—minor flex over CRD).

Summary: Before getting out the config chainsaw, poke at audio devices, dummy displays, and sometimes just restarting the CRD session and relogging does it (Ubuntu occasionally borks user session management after sleep/hibernation—classic).

CRD is slick when happy but moody at best. If you need reliability, consider keeping a backup tool around. If you’re committed to remote Ubuntu, don’t be afraid to experiment outside the Google bubble—even NoMachine and TigerVNC have their own quirks, but sometimes they just work.