Ahhhh man, I've spent so many hours searching for an answer on google and here! I hope some one can help me.

I have a chrooted environment that I have set up on a few different computers. I need to run xwindows applications and on some of the it works and on some it doesn't. When it doesn't work, say for instance I am trying to start emacs, I get this error:

I have tried setting

before entering the chroot and when inside of it.

My DISPLAY variable is, echo $DISPLAY:

normally and when chrooted.

I do not have any firewalls running on any of the machines.

I am thinking that it is a security option somewhere that is preventing the connection or something but I can not find where this would be.


Thanks,
Scott

Hi.

Unless I'm mistaken (which is entirely possible), apps communicate with X through a socket at:
/tmp/.X11-unix/X0

If you're chrooted, you probably can't access that socket.

Dave

Sounds reasonable to me.

Also, when issuing the "xhost" command, use "xhost +localhost" so you won't open your X server up to the entire world.

Peace...

I didn't have the socket in my /tmp! So I, probably rather foolishly, tried to copy it over to my chroot world. I chrooted in and got the same message, "cannot connect to X server :0.0".

I tried to get more information about this problem so I enabled X11forwarding. I then chrooted in and tried this:

Without the copied socket (/tmp/.X11-unix/X0) it shows me this:

It can't find it so there is no hope of it connecting.

With the socket copied into the chrooted environment I get this:

Its there now but connection refused. My access is being blocked or the socket is not valid after being copied.

So there is a difference and this socket seems to be my problem. I am going to check on the boxes that don't have the problem starting X applications in chroot tomorrow and see if the /tmp/.X11* directories exist in their chrooted environments. If not then maybe this is not a problem after all.

Thanks so much for the information, it has been so helpful!

This morning I thought of adding a symbolic link to X0.

Here's the output after trying the same X11 forwarding test as above:

I guess sym links are not an option.

Why not create a "tmp" directory in the directory you chroot to?

For example, if you chroot someone to "/home/bob", make sure "tmp" (with 777 permissions) exists in /home/bob (i.e. /home/bob/tmp). Then let X create it's directories and sockets as it sees fit.

Peace...

The tmp directory does exist. That is where I tried copying to socket to and then later tried creating the symbolic link in. Tnx

Did you create "/tmp/.X11-unix/" or just "/tmp"? If you create the former, delete the .X11* stuff so "tmp" is empty and let X create the files it wants/needs there itself.

From your message above, it looks like you copied the ".X11-unix" parts of the path to the socket vs letting that get created automagically.

If that doesn't help, a Google search on 'ssh -X chroot' found THIS site, which might help.

Peace...

Well, I did not have to create that tmp directory because it has always been in my chroot environment. I did try creating the .X11-unix and stuff but this was after trying it with just tmp in place.

Those files are not created in chroots environment after chrooting in because there has not been an xserver started in the chrooted environment. That is why I was trying to copy them and then tried to symbolic link them.

It appears, now, that my problem doesn't relate to this socket in tmp/.X11-unix because the machines that do not have a problem starting the x applications also do not have those files. So I am back to thinking this is a premissions thing but I am not sure how that can be when I have used xhost to allow the connection. I have also messed with xauth to see if I could get different results. Here is what I tried with xauth:

From what I have read this will set it up so that the user will have proper permissions to use the xserver, but for my situation this doesn't solve anything. My understanding is that xhost + is supose to open xserver to absolutely everyone so the xauth stuff above is probably redundant.

At this point I am pretty much stumped, again, and I'm tired of reading endless amounts of information that are not providing me any insight. Pushed to my list of-> cannot figure it out and not going to continue trying.

Tnx for the help.

Woops. i accidently posted the message twice.. I can't delete this post?

hypexr, I can confirm that after years the problem persist!
I've spent hours too, without solution.
The only nearest touch I got was to learn that a program called Xnest exists to provide such a feature, but in my debian it doesn't work because it appears restricted to ipv6 which I'm not going to set in. Maybe ipv4 could be switched with adequate configuration.

I just got the solution in hands! (spent DAYS..)

Install openssh-server. If version < 4.9, apply an ad hoc patch as described in http://ulf.zeitform.de/en/documents/sshchroot.html

Then in the configuration file (/etc/ssh/sshd_config) insert:
.
As pointed out in http://www.openbsd.org/cgi-bin/man.c...ry=sshd_config , all the directory path leading to the chroot must be root owned and no writable by anyone else.

To link an X session, connect to localhost with X11 forwarding:
.
Solved!