I'm using BASH on the command line, logged into another user's PC as root, via SSH.

I wish to send the user currently logged in running an X-session, a popup message, but this is the result:

root@i5:~$ xmessage now                           
Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyError: Can't open display: :0  

The expected result was a popup message on remote machine, saying "now".

I can replicate this on my local machine by starting a local x-session, then in a terminal if I type xmessage now it works, but if in the terminal I su- so I'm root and I try again, I get the same error as above.

I'm also wishing to use this in a script which needs to be run as root by cron, on my local machine and the script in certain instances, will alert me and request that I choose one of two buttons giving feedback to the script.

migrated from stackoverflow.com May 21 '13 at 11:15

This question came from our site for professional and enthusiast programmers.

  • Try "echo $DISPLAY" first (or a regular "who") to see what display to output to, then use xmessage with the -display parameter. – Andy Thompson May 21 '13 at 8:46
  • Thanks Andy. I've rechecked the man page for xmessage and can't seem to find any mention of the -display parameter or it's syntax. – Peter Snow May 21 '13 at 9:36
  • Check that $DISPLAY is set (believe it needs to be) and use either "echo $DISPLAY" or "who" to see display number then run xmessage with -display :0.0 (or similar) and if that fails, check up on display access with xhost/xauth. – Andy Thompson May 21 '13 at 10:14

Opening a popup window on another user's desktop session is a security issue, therefore it is not allowed. Otherwise it could easily be abused for phishing or other malicious tasks. Without special permissions (like superuser access) there is no way to accomplish what you want.

Even with root access on the machine it still is questionable whether you should open a popup window. You have no idea in what situation your popup will appear, or even whether it will appear. Normally, the window manager is in task to handle newly appearing windows. It can place it somewhere on an inactive viewport or similar, so it would not even become visible, albeit open.

There is, however, a standard way of contacting the user on the machine. That is wall. This tool still requires root permissions (to prevent spamming) but it then writes to all open TTYs, effectively notifying the user running an X session. You might want to consider using this instead of a popup window.

  • Good security point. +1 – user111228 May 21 '13 at 9:15
  • Unfortunately I simplified my command to relate only to the problem in hand but in reality, I'm planning to script this and need user feedback via the buttons. Wall does not appear to give away to obtain the user's feedback. – Peter Snow May 21 '13 at 9:18
  • I've updated my post to clarify my usage further. – Peter Snow May 21 '13 at 9:31
  • Hmm, that's tricky because you cannot really know what the user's Desktop will do with your approaching window. Is it possible to have a daemon running on the user's X session which you can contact to display something? That would be a cleaner approach than simply throwing a window on his screen. Such a daemon can be written in a way so that it also would work on text consoles etc. Also, using wall you can ask the user to run a specific command to give you the feedback you would like to get from him. – Alfe May 21 '13 at 9:56

The environment variable $XAUTHORITY holds the path to the file used to hold X11 authorisation cookies. This defaults to ~/.Xauthority if not set.

So, as root, you may find that the following is sufficient to enable you to open windows on a desktop user's display:

export DISPLAY=:0
export XAUTHORITY=~otheruser/.Xauthority
xmessage "Hello, otheruser."

Now, this won't work if the user is not storing their cookies in the default file (this happens on, e.g., recent versions of Fedora). In this case, you can find out what values to set $DISPLAY and $XAUTHORITY to with:

cat /proc/$(echo $(ps -C gnome-shell -o pid=))/environ | xargs --null --max-args=1 | egrep '^(DISPLAY|XAUTHORITY)='

(replacing gnome-shell with the name of the user's window manager, or some other process that you are sure that they will be running).


With the help of this page, I now have the solution which is as follows.

$ su
$ xauth list
peter-aspire-ubuntu/unix:0  MIT-MAGIC-COOKIE-1  1978485c4f8d864503a4e645c77fd802
peter-aspire-ubuntu:0  MIT-MAGIC-COOKIE-1  1978485c4f8d864503a4e645c77fd802
$ DISPLAY=peter-aspire-ubuntu:0
$ export DISPLAY
$ cp /home/peter/.Xauthority /root/.Xauthority
cp: overwrite `/root/.Xauthority'? y
$ xmessage now

The result is as intended and suits all scenarios described in my question.

Thanks to everyone who participated.


One way to do this is to allow for your computer to connect to the remote computer's X server using the xhost tool and X forwarding over SHH. On the remote computer you need to allow for your computer to talk to it. This requires that X11Forwarding is enabled in the SSH daemon running on the remote.

On the remote computer:

xhost <local_ip>

On the local computer:

export DISPLAY=<remote_ip>:<display>
ssh -Y <username>@<remote_ip> <x_application>

For example if your remote is on your local network:

export DISPLAY=
ssh -Y root@ xmessage now &
ssh -Y root@ xeyes &
  • Thanks htor, but I'd like to avoid going to the lengths of X11Forwarding if at all possible, especially for the local application I added in my update above. I'll bear this in mind though for a last resort! – Peter Snow May 21 '13 at 9:38
  • @PeterSnow Also bear in mind that the X forwarding isn't strictly necessary, it only adds to security of the connection. You should be able to do it with only xhost and exporting DISPLAY to the remote. – user111228 May 21 '13 at 9:53

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.