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.

  • Try "echo $DISPLAY" first (or a regular "who") to see what display to output to, then use xmessage with the -display parameter.
    – Andy Thompson
    Commented May 21, 2013 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. Commented May 21, 2013 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
    Commented May 21, 2013 at 10:14

4 Answers 4


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
    Commented May 21, 2013 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. Commented May 21, 2013 at 9:18
  • I've updated my post to clarify my usage further. Commented May 21, 2013 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
    Commented May 21, 2013 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 [email protected] xmessage now &
ssh -Y [email protected] 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! Commented May 21, 2013 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
    Commented May 21, 2013 at 9:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .