No protocol specified about dockerfiles HOT 13 CLOSED

@AJNOURI try this:

$ xhost local:root

Then run the chrome image :)

from dockerfiles.

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).

from dockerfiles.

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, where n is the display number of the server.

You can do a ls -la /tmp/.X11-unix to get your display numbers.

from dockerfiles.

@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.

from dockerfiles.

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 [email protected] 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.0

Any 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

from dockerfiles.

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

from dockerfiles.

@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

from dockerfiles.

@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.

from dockerfiles.

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 [email protected] 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

from dockerfiles.

@SeanInSpace @jfrazelle Thanks for the help.

from dockerfiles.

On my ubuntu 14.04, I needed the xhost local:root

Thanks !

from dockerfiles.

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.

from dockerfiles.

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

from dockerfiles.