X11 Forwarding using SSH

So… Can we call this a confirmed issue then?

I found another thread, and asked in there as well: https://forum.snapcraft.io/t/migrate-x11-authentication-cookies-into-snap-environment/116/11

Perhaps it is related?

This issue is definitely confirmed. What remains is a design and someone to implement the design. This is a different issue than the other topic you mentioned.


Ok, thanks for getting back to me!

FWIW exporting XAUTHORITY=$HOME/.Xauthority makes this work as well, so maybe there is something to be done in that regard. Obviously wouldn’t work if the snap in question is not connected to the home interface.


the home interface does not allow access to hidden files so i doubt it has any influence here … also note that HOME="$SNAP_USER_DATA" by default.

Right, so it’s probably the x11 interface that allows access to .Xauthority.

Also, by $HOME I mean the host $HOME.

The x11 interface uses the X apparmor abstraction which has owner @{HOME}/.Xauthority r,. This is why the symlink trick I mentioned in X11 Forwarding using SSH works.

If this were to be fixed, exporting the environment variable is way nicer than creating a symlink. Perhaps snapd could export XAUTHORITY=<real home>/.Xauthority if the x11 interface is connected. I’m pretty sure different distros will set this to other values, so there might be distro-specific code. A good first pass might be to check if XAUTHORITY is already set, and if so, use it otherwise export the one in the user’s real home.


It’s been a while - have there been any progress made to address this issue?

No, it hasn’t been prioritized high since a workaround exists (eg, just set XAUTHORITY in the environment before running the snap. The snap could even do this itself).

The desktop part could in theory do this, but it would have to be careful since all distros may not use the same path to the Xauthority file.

I probably face a similar issue Access X11 in a background service and creating the symlink does fix the issue for me but that’s one extra step and not something I expect the users of snap to be excited about :slight_smile:

The snap can do it itself with: ln -s $(getent passwd $USER|cut -d ':' -f 6)/.Xauthority $HOME/.Xauthority. The desktop helper could to, but see X11 Forwarding using SSH - #11 by Saviq for a better way IMHO.

1 Like

Turns out the snap install version of freecad (v0.18) is also looking for .Xauthority in all the wrong places when I try to run it remotely via

% ssh -X

The woggling thing is that virtually all other X-apps work, with the exception of ‘brave’ which I downloaded solely to confirm that it too (still) doesn’t have an .Xauthority fix.

For FreeCAD, taking jdstrand’s advice (thank you),

% ln -s ~/.Xauthority ~/snap/freecad/current/.Xauthority

turned “X11 connection rejected because of wrong authentication.” into Success.

IMHO “Wrong authentication” is gobbledy-gook-speak for “Can’t find an .Xauthority file.”


so i ran into this. i can confirm that just exporting XAUTHORITY=$HOME/.Xauthority does indeed help when ssh’ed into a remote machine, but it makes it more difficult to run with the syntax of ssh -YC remote@machine application
creating a symlink does resolve it for that usecase so that approach seems to work better.

interesting enough when I echo XAUTHORITY is set so perhaps we could at least make snap use that variable? can i assume this would be need to be done in snapd?

Thank you @jdstrand for your solution.

This reply is to inform whoever is in charge that this issue continues to exist and has cost me a lot of time until I found this thread.

Here is the situation:

  • running a remote VM with:
    • Ubuntu 20.04.3 LTS
    • Xfce
  • accessing it from a Windows 10 client via RDP
  • default chromium install via snap
    ( XAUTHORITY had already been set before chromium installation)
  • starting from command line just yielded this message:
    “No protocol specified … ERROR:browser_main_loop.cc(…)] Unable to open X display.”
    (while a browser like firefox (without snap) was working fine after installation)

@jdstrand’s sym-link solution solved the issue and I wonder why this continues to exist after such a long time and causing so much pain…

I just spent a few hours tracking this down again, as Jammy made snap the supported way to run firefox, but apparently this still isn’t fixed. Is there something pending? Can I bump up the priority just based on likely numbers of users affected?

See also https://www.technomancer.com/archives/616

well, you could try to create a firefox bug instead of commenting on an old, unrelated snapd thread :wink:

… that is usually a good way to make the actual maintainers aware …

I guess I don’t know who’s responsible for what WRT this issue (I know almost nothing about snaps in general, just trying to be a user), but clearly much of this thread is specifically about this specific issue of “$HOME is changed so the default lookup of a specific dotfile is broken”, so “unrelated” seems inaccurate. By “firefox bug” do you mean with mozilla.org? Are they the ones responsible for the details of how the snap should run?

1 Like

you linked to a thread that asked about adding a variable to the firefox launcher … so yes, file it at mozilla.org, they are the ones doing the snap …

That thread was, like me, only suggesting a possibility without any real knowledge of where the fix should be or who owns that code. It’s really really difficult for an outsider to find a clue about things like that.

So, thanks for your advice; I will attempt to file it at mozilla.org (five years after the issue was first reported).

Since this is a problem people running snaps over X11 will continue to run into, perhaps you could include the suggestions in your OP so people don’t need to read the entire thread? Apparently, according to ogra via #snapcraft irc:

no, linking wont help … that would allow to break out of the sandbox snaps use apparmr to confine disk/filesystem access … apparmor does not allow to follow symlinks

The answer for Ubuntu 22.04 was

$ tail -2 ~/.bashrc
##added 2023.01.04 from https://forum.snapcraft.io/t/x11-forwarding-using-ssh/2381
export XAUTHORITY="$HOME/.Xauthority"