I’m trying to use Anydesk but I keep getting a ‘Display_server_not_supported’ error. I can’t connect to my remote device, and this just started happening after a recent update. Has anyone run into this before or know how to fix it? Looking for urgent help as I rely on Anydesk for work.
AnyDesk and Linux Remote Woes: Wayland Strikes Again
So here’s the deal: that annoying error you’re seeing? Nine times out of ten, it’s because the computer you’re trying to connect to has a display setup that AnyDesk can’t handle. Specifically, this sneaky little devil called Wayland is often running the show on modern Linux distros, and for some reason, AnyDesk just can’t get its hooks into it.
Here’s What You Can Try (from someone who’s been burned too many times):
-
Ditch Wayland for X11 for Now
- When you’re at the login screen, look for a little gear icon or a “session” option. Pick “GNOME on Xorg” (or “X11” or whatever looks close — distributions love to get cute with the names). Log in like normal.
- Seriously, X11 is ancient, but it lets AnyDesk do its thing. Think of it like taking the bumpy road because the highway’s under construction.
-
Enable Compatibility Modes or Unattended Access
- Some distros give you a magic switch called “compatibility mode” when launching AnyDesk. If it’s there, use it.
- Even better: set up unattended access, so you don’t need the remote user to click anything. Life’s too short for endless hand-holding.
-
Don’t Connect Before the Desktop’s Ready
- If you’re trying to jump in before anyone’s logged in and started a session, you’re gonna have a bad time. AnyDesk usually needs the user session — that’s when the display server spins up. If you see the login box, wait till someone’s in.
Real Talk: Wayland Isn’t Fully There Yet
Wayland’s supposed to be the future — fewer bugs, better security — but right now, remote desktop tools like AnyDesk are still playing catch-up. You might get it to work, or you might be asked to “try again later” for the tenth time, like you’re waiting at the DMV.
If you need solid, hassle-free remote access? X11 is old, but for now, it’s the path of least resistance. Give it a try and watch the error vanish.
Feel free to stack other workarounds or check AnyDesk’s Linux support page for new tips as the landscape keeps shifting.
25 Likes
Let’s be real: “Display_server_not_supported” is just code for “No soup for you!” when it comes to remoting in with AnyDesk on Linux with fancy display tech. @mikeappsreviewer is right that it’s mostly due to the wacky Wayland vs. X11 battle, but honestly, just switching to X11 every time isn’t always a long-term fix for everyone—especially if you’re on a distro that’s trying to banish X11 to “legacy” status.
What I’ve noticed, especially after those big, mysterious updates that break everything (thanks, Ubuntu/Fedora maintainers…), is that AnyDesk really hasn’t kept up with the latest Wayland permissions or session management tricks. Even if you’re on X11, sometimes the error persists because AnyDesk gets tripped up by system permissions, newer kernel sandboxing, or—my personal favorite—flatpak/snap packaging sandboxing its access. Also, if you’re running in a VM or have Nvidia drivers involved, buckle up; that’s another fun dimension.
So, before ritualistically chanting “log in to X11 not Wayland”, consider these:
- Check Wayland enablement: If your distro FORCES Wayland now (looking at you, Fedora/Ubuntu 22.04+), sometimes there’s a hidden settings file (e.g.
/etc/gdm3/custom.confor equivalent) where you can comment out “WaylandEnable=false” and force GDM back to Xorg/X11 system wide. Not always obvious at login. - Try AnyDesk beta/dev/older versions: Sometimes, weirdly, an older AnyDesk works because it had more X11 hooks left in place. Or see if there’s a beta with better Wayland support (if you’re brave/desperate).
- Check user permissions: After some updates, PolicyKit or user session configs get overwritten. Make sure your user has a part in “video” or “remote desktop” groups. Look for logs in
/var/log/syslogorjournalctlfor AnyDesk session errors. - Tweak package install: Snap/Flatpak versions of AnyDesk are notorious for sandboxing issues with display servers, especially with input injection. Get the official .deb or .rpm and install from terminal (no software centers!) to dodge this.
- Try another remote access tool: Not trying to start a remote desktop war, but sometimes RustDesk, NoMachine, or even the old-school VNC just “work” when AnyDesk throws a fit on Wayland.
Frankly, every so-called “upgrade” in the Linux world feels a bit like Russian Roulette for remote desktop users. X11 “just works” more often (I won’t argue with the results), but expecting regular users to keep fiddling with login managers, configs, and session selection every update isn’t what I’d call a real solution.
TL;DR: The error’s about AnyDesk not playing nice with your display server, mostly Wayland drama, but also sometimes user/session permission issues, sandboxing, or packaging. Try those deeper tweaks if just swapping X11/Wayland doesn’t fix it. And yeah, keep an eye on competitor writeups like the one by @mikeappsreviewer for the latest hacks as the mess evolves.
Honestly, people make this WAY too complicated. The “Display_server_not_supported” message in AnyDesk is basically a big sign saying, “Sorry, we’re not friends with your display manager today.” Yeah, everyone and their dog will shout WAYLAND! like it’s some sort of secret code, and sure, the stuff @mikeappsreviewer and @viaggiatoresolare said holds up—Wayland vs. X11 is the main battle here. But let’s admit it: swapping back to X11 every time your system updates is like hacking off a leg because your shoe doesn’t fit. With distros hard-pushing Wayland, this isn’t a long-term fix.
What’s REALLY annoying: Sometimes you’re already on X11, and AnyDesk still whines. That’s usually NOT because you forgot to pick the right session. Look deeper: a lot of newer Linux systems now shove AnyDesk into a sandbox (snap/flatpak install, lookin’ at you). That’ll break direct display connections and input even if X11’s doing its thing. If you installed AnyDesk from Software Center, try the official .deb or .rpm from their site—no sandbox, better chance of success.
Permissions? Bruh, Linux isn’t Windows. Random desktop app updates CAN actually break PolicyKit rules or group memberships. On my Pop!_OS box, after a big upgrade, I suddenly had to manually slap myself back into the “video” group—no prompt, no warning, just… broken remote access. Check your user groups (with groups in terminal), and if the error sticks, snoop in the logs (journalctl -xe | grep anydesk).
Also, small thing, but NVIDIA drivers sometimes block screen capture or hardware acceleration features needed by AnyDesk—totally random, I know, but I had to downgrade my GPU driver ONCE just to get remote desktop working again on my main PC. Total pain.
So, while @mikeappsreviewer and @viaggiatoresolare covered almost all causes, I wouldn’t stress too much about session swapping unless you really NEED AnyDesk. Honestly, if you’re not doing rocket science over that connection, just use another tool temporarily—RustDesk, X2Go, NoMachine, whatever. It’s 2024 and… remote desktop on Linux still feels like punching yourself in the face with every update cycle.
In short: don’t always assume it’s only Wayland. Look at how AnyDesk was installed (skip snaps and flatpaks), your user’s permissions, and yeah, even your GPU drivers. Or, y’know, scream into the void—that works for me about half the time and wastes zero calories.
You know what’s hilarious about remote desktop in Linux land? It’s all about musical chairs—switch display servers, swap install methods, pray your user groups haven’t changed since last Tuesday, and you MIGHT get in. The “Display_server_not_supported” error in AnyDesk is almost never just one thing (despite what some folks say about always blaming Wayland, which, sure, is often guilty-as-charged).
But let’s zag where others zig. Forget for a second about the usual Wayland/X11 wars. I’ve seen “Display_server_not_supported” pop up because of one sneaky culprit: graphical session permissions, specifically with modern compositors and polkit rules. Here’s a curveball—if you’re running a fancy desktop environment (hello, KDE Plasma 6) with layered security, you may hit this error if AnyDesk doesn’t get “screen capture” rights in the new permission dialogues (especially after a distro upgrade). Sometimes the message doesn’t indicate this, but check if screen-sharing permissions are lurking in the system tray or under “privacy” in your system settings. Grant them, and—presto—AnyDesk reconnects.
Also, love the insights from the other folks about sandboxed installs (snap/flatpak), but just reinstalling the .deb/.rpm isn’t always enough. Sometimes you’ve gotta nuke residual configs (rm -rf ~/.config/AnyDesk) because leftover settings can freeze permissions on first run. Not fun, but effective.
Let’s talk alternatives since AnyDesk isn’t flawless and all the “fixes” feel like duct tape. RustDesk is open source, great for quick setups with no vendor server, but light on power user features. X2Go is old school but rock solid on X11, if you don’t need graphics acceleration. NoMachine is polished but adds its own connectivity quirks, especially with NVIDIA. AnyDesk’s perks: great performance, solid mobile support, and generally easier firewall traversal—which, for non-techies, is worth the occasional handshake with X11’s ghosts. Cons: closed source, persnickety with modern Linux, and you never can trust it after a major update.
So before you rage-quit or start a support group for “Remote Desktop PTSD,” double-check session permissions, purge weird configs, and, worst case, jump to another tool if today’s AnyDesk mood isn’t lining up with your patience. This dance isn’t ending until Linux remote desktop vendors get their Wayland act together, so keep a backup plan handy.