No protocol specified
AJNOURI opened this issue ยท 13 comments
Hi Jessica,
Where these options work for many GUI applications:
-v /tmp/.X11-unix:/tmp/.X11-unix \
-v /dev/snd:/dev/snd \
-e DISPLAY=unix$DISPLAY \
this output is the most frequent when it doesn't work:
No protocol specified
<entrypoint>: cannot connect to X server :0.0
Any thoughts on this?
(I hope it is the appropriate place for this question.)
If you echo $DISPLAY what do you get? Are you on linux or a Mac? Which
image are you seeing this on?
On Thursday, March 5, 2015, AJ NOURI notifications@github.com wrote:
Hi Jessica,
Where these options works for many GUI applications:
-v /tmp/.X11-unix:/tmp/.X11-unix
-v /dev/snd:/dev/snd
-e DISPLAY=unix$DISPLAY \this output is the most frequent when it doesn't work:
No protocol specified
: cannot connect to X server :0.0Any thoughts on this?
(I hope it is the appropriate place for this question.)
โ
Reply to this email directly or view it on GitHub
#6.
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3
Linux gns3-iouvm 3.13.0-46-generic #77-Ubuntu SMP Mon Mar 2 18:23:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 14.04.2 LTS
Release: 14.04
Codename: trusty
These are the images I built:
https://github.com/AJNOURI/Docker-files/tree/master/testing
sudo docker build -t ostinatoimg -f ostinato-docker .
sudo docker build -t linphoneimg -f linphone-docker .
echo $DISPLAY
:0.0
and the result of running them:
ostinato image
sudo docker run -v /tmp/.X11-unix:/tmp/.X11-unix
-e DISPLAY=unix$DISPLAY ostinatoimg
No protocol specified
drone: cannot connect to X server unix:0.0
linphone image
sudo docker run -v /tmp/.X11-unix:/tmp/.X11-unix \
-v /dev/snd:/dev/snd -e DISPLAY=unix$DISPLAY linphoneimg
No protocol specified
@SeanInSpace Indeed, that makes it work for both images. Thanks
But, why should I explicitly allow localhost:root to access local X server?
Shouldn't be enough to map X11 socket and set the environment?
-v /tmp/.X11-unix:/tmp/.X11-unix
-e DISPLAY=unix$DISPLAY
@AJNOURI no problem. I'm not sure, I think it's because X is restricted to your user and not root, but when you sudo
a container it's trying to access X as root?
Maybe @jfrazelle can tell us how she does it/has a better explanation.
I don't sudo docker I added my user to the group, I have never needed to
run anything with xhost, I just have seen other people have needed that,
not really sure as to why could be defaults set by their specific distro etc
On Monday, March 9, 2015, Sean notifications@github.com wrote:
@AJNOURI https://github.com/AJNOURI no problem. I'm not sure, I think
it's because X is restricted to your user and not root, but when you sudo
a container it's trying to access X as root?Maybe @jfrazelle https://github.com/jfrazelle can tell us how she does
it/has a better explanation.โ
Reply to this email directly or view it on GitHub
#6 (comment).
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3
@SeanInSpace @jfrazelle Thanks for the help.
On my ubuntu 14.04, I needed the xhost local:root
Thanks !
If not using sudo, then you can also just add xhost local:docker
It worked for me at least, running on Elementary OS (Ubuntu 16.04).
Running the aforementioned xhost
command is temporary until the Xserver restarts (on reboot, or otherwise). As per the man page:
The initial access control list for display number
n
may be set by the file /etc/Xn
.hosts, wheren
is the display number of the server.
You can do a ls -la /tmp/.X11-unix
to get your display numbers.
@jonashartmann Unless this works differently on Ubuntu, xhost local:docker
is the same as xhost local:
. So this just allows access to local "everyone". From the xhost manpage:
local contains only one name, the empty string
Try running xhost
without arguments afterward, and you'll see that the :docker
part was ignored. To allow access to the docker group, you could use xhost si:usergroup:docker
(see this):
The sample implementation includes several Server Interpreted mechanisms:
IPv6 IPv6 literal addresses
hostname Network host name
localuser Local connection user id
localgroup Local connection group id
However, this won't work either, because the docker
group doesn't exist in the container. Essentially, X looks at the UID of whoever is trying to run a GUI on its server, and checks the xhost list for that UID.
You can either create a dummy user on the host that you map to the container user, or assign your user's UID to the container user.
Here's a good rundown on some different ways this can be configured.
If you want a simpler want of doing this you should check out the sommelier
utility developed for ChromeOS. https://chromium.googlesource.com/chromiumos/platform2/+/master/vm_tools/sommelier/
You may still need to do xhost local:
before running the containers after enabling Sommelier, but in a Linux VM in ChromeOS that is the only change I had to make.
How-to that should be somewhat applicable if you aren't running under ChromeOS where it comes preinstalled in the Linux VM.
https://github.com/dnschneid/crouton/wiki/Sommelier-(A-more-native-alternative-to-xiwi)
I noticed that in her Xsession file that Jess has an xhost line which might be why she hasn't had to run it separately.
If not using sudo, then you can also just add
xhost local:docker
It worked for me at least, running on Elementary OS (Ubuntu 16.04).
Works for ubuntu 18.04