1

I'm running a HelpDesk for internal call center employees. All employees have headsets in conjunction with their jobs, and I'm working on a script to remotely launch a minimized Mumble session via SSH in order to better aid in remote support. All remote users are using Linux Mint XFCE.

I followed Oli's top solution to the question How to start a GUI software on a remote Linux PC via SSH, and I used his example to write this bit of code to launch Devilspie (which I've pre-configured to minimize Mumble) and then launch Mumble itself:

export DISPLAY=:0
devilspie & echo loading devilspie
mumble

When I test this code while logged in as the remote admin profile, it works like a charm. Devilspie launches, and then Mumble launches to immediately minimize. My problem, however, is that the end-users I'm trying to support aren't administrators on their workstations. If I run this same script via SSH while the remote machine is logged in as a non-admin user, Devilspie gives me the following error:

No protocol specified
Gdk-WARNING **: devilspie: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

and Mumble gives me the following error:

 No protocol specified
 mumble: cannot connect to X server :0

Since this same script works flawlessly on an admin profile, I'm presuming that the error may have something to do with permissions. Help! I can't figure out how to launch these applications for a non-admin user.

Community
  • 1
Jared Dalton
  • 139
  • So each user has a local Linux Mint desktop, SSHing to a remote linux machine? Is that correct? What's the commend they're using to SSH to the remote machine? – John May 04 '15 at 18:35
  • So you want to connect to a remote host, and start an X app that will display there, remotely (rather than on the client)? – dhag May 04 '15 at 18:42
  • @John I'm using PuTTY to SSH from my workstation into the remote Linux machine where an employee is sitting. I use the remote admin user "tech@RemoteComputer" to login to the SSH session, with the tech password. If I'm logged into the remote workstation as tech, my script works, but if not, then I get the aforementioned errors. – Jared Dalton May 04 '15 at 18:43
  • @dhag Yes, that's correct. – Jared Dalton May 04 '15 at 18:44
  • If you're not logged in as "tech" on the remote computer, the user ID you're logged in as will have to do additional stuff to make this work... Not sure what your desired end-state is, but you're doing things in a rather unusual way so far. – John May 04 '15 at 18:46

1 Answers1

2

If I've understood the question correctly:

  • A workstation is running X, and user $USER is logged in
  • User $ADMIN wants to start an X client on that machine, and connect to the X server of $USER.

If you have control of the X session's startup, you should be able to arrange (perhaps in $USER's .xsession) to give access to $ADMIN using xhost:

xhost +SI:localuser:$ADMIN

I sometimes use this technique when debugging embedded devices with X displays.

See the man page for xhost for the full set of options.

Toby Speight
  • 8,678
  • Alas, when I run that command, I get the error: 
     xhost:  unable to open display ""

    As far as your summary, that is correct though. In this example, I'm logged into SSH using the admin-user "tech" while the workstation itself is logged in as the non-admin user "tagent".

     – Jared Dalton May 04 '15 at 18:58
  • This really looks like the proper answer; once you manage to run it in an environment that has permission to access that X display, it should allow the script in your question to work. – dhag May 04 '15 at 19:07
  • @JaredDalton how did you run the xhost command? from where, and as which user? AFAIK it needs to be run as the local user (i.e. tagent) with the DISPLAY environment variable set appropriately for tagent's physical display (likely DISPLAY=:0, but this is not guaranteed). – steeldriver May 04 '15 at 19:50
  • It needs to be run in an environment that already has access to the X server. My suggestion is to get it into the user's .xsession - or perhaps (more cleanly, and for all users) in /etc/X11/Xsession.d/. And of course, that won't have any effect on current sessions - you'll need to wait until the user next logs in. – Toby Speight May 05 '15 at 08:15