ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] (wireshark:26800): Gtk-WARNING **: cannot open display:

From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Wed, 12 Dec 2007 08:27:05 +0100
Hi,

Yet again this is not a Wireshark problem. This has to do with access control to your X server. You don't want just anybody opening windows on your screen, do you. So if you started the X server under your own account (greg) then any other user (like root) doesn't have access to it.

You have two ways to get this working: grant it or have root take it.
You (greg) can grant it by means of 'xhost local:root'. Or root can take it, because it can access your files:
'export AUTHORITY=/home/greg/.Xauthority'.

Thanx,
Jaap


Greg Toombs wrote:
Stephen Fisher wrote:
Wireshark doesn't install any window manager specific things at this time other than providing a wireshark.desktop file.
Right, but the desktop file should have two entries, not one. (Or two
desktop files? I don't know how it works.) This is done by default in
Ubuntu, for one.
sudo/su doesn't always carry your environment variables to the program being run as root.  To verify this is happening, try sudo echo $DISPLAY and verify it is blank.
echo $display
:0.0

sudo echo $display:
:0.0

sudo su
echo $display
<blank>
If so, try adding the DISPLAY variable assignment to your root shell's startup dot-file and see if that works.
When I su and then set the variable, the output changes to:

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

(wireshark:26949): Gtk-WARNING **: cannot open display: :0.0

 Your sudo may also have an option to preserve environment variables such as DISPLAY when running. I don't have a Linux machine handy at the moment to try it out, but on MacOS X sudo does preserve environment variables and has an option not to.
I think it would be more proper to set the default environmental
variables for the root user, instead of temporarily transferring those
from the non-root to root user during sudo. Either way, it looks like it
isn't just a $display problem.