On my local machine, I run:

ssh -X [email protected]

(For completeness, I have also tested all of the following using -Y with identical results).

As expected, this accesses remotemachine.com fine, and all appears well. If I then attempt to run xcalc however, I get:

 connect /tmp/.X11-unix/X0: No such file or directory
 Error: Can't open display: localhost:10.0


$ ls -la /tmp/.X11-unix/
total 36
drwxrwxrwt 2 root root  4096 2012-11-23 09:29 .
drwxrwxrwt 8 root root 32768 2012-11-29 08:22 ..
srwxrwxrwx 1 root root     0 2012-11-23 09:29 X0

So not only does /tmp/.X11-unix/X0 exist, it has universal r/w/x permissions!

I've previously used x-forwarding without issue, though not in some time...

uname -a on the server for reference:

Linux machinename 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux

Been searching around on the web for a couple hours now without success. Other mentions of the same problem, but no solutions.

  • Note that it's the file on the local machine that you need to check here, not the remote one. I would use strace -fo /tmp/trace ssh.... to check that it does try to connect that Unix domain socket. Commented Nov 29, 2012 at 14:27
  • Ah! That could be it. Strangely, my local machine does not have a /tmp/.X11-unix/ directory though. Commented Nov 29, 2012 at 14:46

11 Answers 11


I had the same problem with Cygwin and Xming, connecting to a remote Linux server.

My $DISPLAY variable was simply ":0.0" in Cygwin, and although that works locally, it didn't work with the remote ssh command.

Changing the variable to "localhost:0.0" on the local machine fixed the issue.

export DISPLAY=localhost:0.0

Once I did that, my command worked:

ssh -Yf user@host gvim somefile.c
  • 7
    This was the problem for me even using Windows Services for Linux.
    – lapo
    Commented Oct 3, 2017 at 9:27
  • 2
    On which server did you run the export ... command? 1) local machine 2) server
    – abalter
    Commented May 24, 2018 at 4:27
  • 1
    @abalter It worked for me running it on the local machine
    – tralston
    Commented Jul 21, 2018 at 3:21
  • 4
    I spent 2 hour debugging issue with Cygwin ssh + VcXsrv because I set DISPLAY=:0 ssh -Y $host. Changing it to DISPLAY=localhost:0 magically solved problem.
    – gavenkoa
    Commented Oct 2, 2018 at 20:00
  • 2
    Indeed, export DISPLAY=localhost:0.0 in ~/.bashrc is the way to go for WSL Commented Apr 17, 2019 at 18:28

If you have a X server running and the DISPLAY environment variable is set to :0, that tells applications to connect to the X server using a unix domain socket which is generally to be found on Linux in /tmp/.X11-unix/X0 (though see below about the abstract namespace on recent Linux).

When you ssh to machine remotemachine, sshd on remotemachine sets DISPLAY to localhost:10 (for instance), which this time means that X connections are do be done over TCP to port 6010 of machine localhost. sshd on remotemachine listens for connections on there and forwards any incoming connection to the ssh client. The ssh client then tries to connect to /tmp/.X11-unix/X0 (on the local end, not the remote) to contact your X server.

Now, maybe you don't have a X server running (are you on Mac?) or maybe the unix domain socket is not to be found in /tmp/.X11-unix which would mean ssh hasn't been configured properly at compile time.

To figure out what the proper path is for the unix socket, you could try a strace -e connect xlogo (or the equivalent on your system) on your local machine to see what a normal X application does.

netstat -x | grep X may also give a clue.

For the record, on a Linux Debian wheezy machine here, Xorg listens on both /tmp/.X11-unix/X0 in the filesystem and /tmp/.X11-unix/X0 on the abstract namespace (generally written @/tmp/.X11-unix/X0). From strace, X11 applications seem to now use that abstract namespace by default, which explains why those still work if /tmp/.X11-unix is removed, while ssh doesn't use that abstract namespace.

  • 2
    Or check lsof -p <PID of your local X server> where you should be able to find the /some/thing/Xn file, the n being your DISPLAY number.
    – peterph
    Commented Nov 29, 2012 at 14:58
  • Thanks, this was quite helpful. Somehow my /tmp/.X11-unix/X0 file was removed, although there was still an X server running. A quick reboot seems to have resolved the problem. Possibly caused by some updates I did a while back. Commented Nov 29, 2012 at 15:00
  • 10
    Changing the DISPLAY variable from ":0.0" to "localhost:0.0" seems to have done the trick for me, at least connecting from Cygwin to Linux.
    – m0j0
    Commented Aug 4, 2015 at 23:28
  • FWIW, I had to run startxwin (after apt-cyg install xinit) from the cygwin host because I'm connecting local Windows to remote unix
    – Jonathan
    Commented Sep 6, 2016 at 22:47

This is complementing other answers with information specific from Windows-Subsystem for Linux (WSL). The accepted answer is correct: your DISPLAY variable is incorrectly configured. It's not exactly clear, however, why that's the case from that answer alone, so I'm remediating with this answer.

If you are running cygwin, or Windows-Subsystem for Linux, and your X11 server is windows-based (e.g. VcXsrv, or XMing), it is more likely that your X11 server is listening on a TCP port (such as port 6000-6010) than on the default Unix domain socket (/tmp/.X11-unix/X0). Unix sockets are not well-supported on Windows at this point in time, even inside WSL. Communicating between programs in the Linux-like environment and programs running directly on the windows host is also generally easier over IP sockets.

When you run graphical applications locally (i.e. from the Cygwin or WSL environment of your host), and your DISPLAY variable is set to the default (i.e. DISPLAY=:0.0), applications will first attempt to connect to the X server via the Unix socket /tmp/.X11-unix/X0. This will fail, but most applications will then fallback to a TCP connection on localhost, which should succeed in reaching the server, assuming your X server is configured with defaults.

You could confirm that this is happening by looking for connect() calls in strace logs from a run of your graphical application. Those would generally happen early on, before the main window of the application appears.

The catch: That fallback behaviour doesn't happen when ssh is redirecting a connection from the remote side, so you are getting that error. sshd on the remote will indeed forward the X11 connection to the local side, but the ssh client's local connection dead-ends as it fails to reach out to the server over the Unix socket. You are then getting the ENOENT error. It doesn't try the fallback connection to TCP localhost.

The fix: In such cases, changing your DISPLAY variable to use the TCP syntax instead of the :0.0 syntax, can fix the issue:

DISPLAY= ssh remote some-gui-application

Like other answers mention, you can also export that variable interactively from your shell prompt:

$ export DISPLAY=
$ ssh remote some-gui-application

You can also store this setting more permanently by adding that line to your login shell profile initialization script (e.g. ~/.bash_profile).

Note: Some shells have a different initialization script for login and non-login sessions. For instance, with bash you could write that line to the non-login script, i.e. ~/.bashrc, instead of ~/.bash_profile. If you do, be careful not to override any custom value that might have been set by ssh. That would be the case if you were hopping first into your host via ssh and then hopping again into another host (thus nesting your X11 forwarding).

  • 2
    I've come across many answers to this kind of question and this is the only one which helped me. +1 Commented Feb 5, 2020 at 22:21
  • 1
    I have been trying to forward X from my Arch linux to my Windows 10 WSL with Ubuntu and vcxsrv and this solved my problem, thanks! Commented Apr 6, 2020 at 9:18

If your display host happens to be macOS, make sure you have XQuartz running.

This error message is telling you the ssh tunnel is working, but it can't figure out how to connect to the X server on your side of the tunnel.

In the good old days, Mac OS X used to start XQuartz for you, but we have apparently abandoned this nice little feature in the macOS version of terminal.

  • follow up: Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open display: localhost:10.0 meant "you need to exit out and SSH back in after starting XQuartz" FWIW...
    – rogerdpack
    Commented Feb 5, 2019 at 20:07

I just had the same problem. The confusing thing is that you get the no-such-file error on the remote machine, but actually this file is missing on the local (display) machine.

Just to see what would happen, I manually created the missing file (fifo, actually), on the display machine, like this:

mkfifo /tmp/.X11-unix/X0

Then ssh'ed into remote machine again, and lo and behold, X11 connected fine.

I don't know if this is relevant or not, but my display machine is not Linux, it's Windows with cygwin and VcXsrv. (The remote machine is Linux)

  • 6
    /tmp/.X11-unix/X0 is a unix domain socket, not a FIFO
    – Samveen
    Commented Jun 5, 2015 at 5:13

I found that in WSL/Ubuntu, my ~/.bashrc had the line

$ export DISPLAY=:0

at the end of it.

Removing this line and restarting the WSL/Ubuntu app, I found that the DISPLAY environment variable was set correctly to

$ echo $DISPLAY

Now ssh into the remote machine using

ssh -X [email protected]

works and can pop up windows in the remote machine.


I ran into this problem using the Windows Subsystem for Linux. The issue is I didn't have a GUI installed on the client, because of the assumption that since it's a Windows machine, I have a GUI.

To test if you have a GUI, execute xclock on the client. If you get the error Error: Can't open display: :0 then you need to install a GUI program for Windows. I used Xserver.

Once you have a GUI installed, try the following commands:

export DISPLAY=:0

If a clock comes up, then success!

Now try ssh'ing into the server, then running xclock. Did you get still get the error messages connect /tmp/.X11-unix/X0: No such file or directory Error: Can't open display: localhost:10.0? That's because the server is trying to connect to itself to display the GUI. Instead, you want the DISPLAY variable set to an address where the server can get your computer. So if it's on a LAN, you would just put in your computer's name. If you are connecting to a server on the WAN, then you need to specify your router's external IP and have the proper port forwarded.

LAN: export DISPLAY=ComputerName:0
WAN: export DISPLAY=

  • "X forwarding" means "tunnel the X protocol from applications running on the remote machine (server, in your case) to the local machine (client, in your case)", so of course you need to run an X server (and not "any GUI program") on the local machine. Windows by itself doesn't understand the X protocol, even though "you have a GUI".
    – dirkt
    Commented Oct 29, 2018 at 7:23

I had the same issue with cygwin.

I solved it with starting following *.bat-script

@echo off

chdir C:\cygwin\bin
run XWin -multiwindow -clipboard -silent-dup-error
run mintty.exe -i /Cygwin-Terminal.ico -

source: https://www.asc.tuwien.ac.at/eprog/download/win10_Anleitung.mp4

  • This was how I solved it first (based on your anwser), but it actually starts another XServer on my machine.
    – le_top
    Commented Apr 4, 2023 at 21:32

(I only saw that some replies mention the solution after finding the fix myself - so summarizing my issues and fixes a bit here).

In summary:

  • Do not set DISPLAY=:0 but set DISPLAY=localhost:0 on your client.
  • You may need AddressFamily inet in /etc/ssh/sshd_config on the remote host.
  • You may need to ensure your not changing DISPLAY in the remote account (.profile, .bashrc).
  • If you get an error like "Cannot connect to localhost 6000", then your local XServer may not be running (the remote port is usually 6010 as on the remote host, DISPLAY is set to localhost:10.0 in most cases).

I got the error message connect /tmp/.X11-unix/X0: No such file or directory, when starting xterm, after successfully connecting to my remote server using Cygwin's ssh.

I then struck to me that /tmp/.X11-unix/X0 was actually refering to a socket local to my ssh client.

I was using MobaXterm to provide the XServer which is using another Cygwin context (in my case /tmp maps to C:\Users\USER\AppData\Local\Temp\Mxt230\tmp).

By locally defining the DISPLAY using a hostname/IP, ssh -X does the correct mapping. However, that shows that local executions of ssh -X and xterm are not interpreting DISPLAY=:0' the same way. xtermopens the Xterm window on my MobaXterm XServer, butssh -X` is not forwarding to it.

Last thing that may be important: I had to set AddressFamily inet in /etc/ssh/sshd_config, and restart the server's sshd as well to fix X11 forwarding request failed on channel 0.

And on certain hosts, I had to change DISPLAY=:0 in the .profile setup script to DISPLAY=${DISPLAY:=:0} to avoid overriding the DISPLAY set by ssh -X (these embedded hosts "need" that - somewhat out of my control).

Finally, I ran into a connection issue on localhost, port 6000 when trying to start the X application on the remote host. I was expecting port 6010 - my local MobaXterm XServer was actually defunct and I had to restart it.


Same error, but different root cause than the posted answers.

I have Windows 10 with cygwin/X, which I use to ssh to a remote machine with X11 forwarding. It failed with the error:

connect /tmp/.X11-unix/X0: No such file or directory
Error: Can't open display: localhost:10.0

because I was accidentally using the ssh client from Windows (OpenSSH from Windows). That version of ssh does not know how to connect to a local X11 display, which causes the problem.

We can see it by checking the version:

$ ssh -V
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

Solution: install ssh in cygwin and use that one.


If it was working fine and stopped working without any proper reason, Probably it could be an uncontrolled X instance running in the background. Please close that using task manager.


You must log in to answer this question.

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