Why does my X11 forwarding attempt fail with "connect /tmp/.X11-unix/X0: No such file or directory"?
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
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.
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 127.0.0.1 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=127.0.0.1:0 ssh remote some-gui-application
Like other answers mention, you can also export that variable interactively from your shell prompt:
$ export DISPLAY=127.0.0.1:0
...
$ 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).