2

I have mac with xquartz as a remote client for X11 on my latest ubuntu linux. I am able to connect with ssh and start applications like xclock remotely. With most of the apps like gnome-calculator the app opens in ubuntu local display instead of remote display as intended. SSH configuration should be fine and to my best understanding this has something to do with display parameter in x11 forwarding. Any help will be appreciated.

3

I had the same problem with ssh -X user@remote. Some applications are showing on local side (e.g. xclock), and some on the remote side (e.g. gedit). I believe this is a problem is with all GTK/Gnome applications. It only happened when a remote display was running (I was using NoMachine at the same time)

I found a workaround: unset XDG_RUNTIME_DIR environment variable.

ssh -X -C user@remote
unset XDG_RUNTIME_DIR
gnome-calculator

The same effect is by using su - $USER. The - is important here

ssh -X -C user@remote
su - $USER
gnome-calculator

Now application shows on local display always, even when a remote desktop is opened.

4
  • Hello, I've posted an answer that could be interesting for you :) – pa4080 Mar 13 '20 at 18:18
  • It isn't related to DISPLAY or XAUTHORITY, but somehow with XDG_RUNTIME_DIR – user2622016 Mar 19 '20 at 23:35
  • thanks, it works, for some extra oddity some apps like gedit and gnome-calculator, while gnome-terminal keeps showing on the other side. Luckily enough there are plenty of other non-gnome terminal options . – user1708042 Apr 14 '20 at 9:38
  • In my case, I had to unset GDK_BACKEND as well as XDG_RUNTIME_DIR - just doing XDG_RUNTIME_DIR resulted in Gtk-WARNING **: 16:50:48.916: cannot open display: localhost:10.0 – Alec May 3 at 16:51
1

Apparently sudo app_name helped. For some reason without sudo the application starts as local instead of remote display. Apparently same user can't be logged in from console same time as remote X connection starts application or it will launch the application in console.

1
  • Fixed my issue where i could run all apps except gnome ones – A Tyshka Oct 26 '18 at 18:11
0

I've read the three posts here, and I think there is a little misunderstanding of the -X option.

The intention of the -X option of the ssh client is to forward a remote display to a local one thus you can run remote resources and view them locally... for more information read man ssh.

When you are using sudo or su these commands just break the normal work of the X-forwarding, thus the GUI applications are running on the remote display. Something more when you are using sudo some-gui-app it breaks the ownership of the files in your $HOME directory, which could cause some issues - the fix is: sudo chown -R $USER:USER $HOME, and next time use sudo -i ... or sudo -H ....

In order to run a GUI application on the remote display from within ssh session, you need to export the values $DISPLAY and $XAUTHORIT (and in some cases some other variables) of the desktop session where you want to run the application - normally this is the active session, where the user is logged-in and the session is displayed on the physical screen.

Time ago, I've developed a bash script that is able to detect the active desktop session and export all its variables from within the current session (ssh|cron|tty|etc.). Initially I needed to solve similar task for crontab, this is the reason of the original name of the script cron-gui-launcher, but it has a wider field of usage. The script, all necessary explanations, and couple of example of usage are available within my GitHub's repository: https://github.com/pa4080/cron-gui-launcher.

Here is a video demonstration how the script works: Ubuntu: CRON GUI Launcher Demo - SSH.

2
  • I noticed that unsetting environment variable XDG_RUNTIME_DIR fixes the issue (a workaround?). Do you know why it works? – user2622016 Mar 19 '20 at 23:33
  • the interesting observation is that IF an X app instance is running on the remote machine your are ssh ing into is diverting the DISPLAY to that machine. so even if you start it remotely with the DISPLAY set to X11 tunnel its not working out of the box. the easy workaround is to stop the instance on the remote. but thats not always an option – U.V. Oct 12 '20 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.