The problem I wanted to solve was to ssh from my laptop to a ubuntu server and then invoke emacsclient to obtain a x window’s frame on my lap top served up from the emacs running on the ubuntu server. The xauth inside emacs is the one into which I needed to add the xauth credentials. The following worked, at least once

This script resides on the ubuntu server is run after you ssh to the server, forwarding your
laptop’s X display.

#!/bin/bash

# First we need to add to xauth of the server emacs
# permission to throw up windows on our X server.
# But .Xauthorization accumlates so we have to auth
# more than you'd think.
xauth -f ~/.Xauthority list | grep -v ':0' | while read foo; do
  emacsclient -e "(shell-command \"xauth add $foo\")"
done

# Ok, now we should now be able to connect.
emacsclient -c

Thanks for the hint!

Thank you.

http://www.cam.hi-ho.ne.jp/oishi/indexen.html

http://executor.dk/

We should have lunch soon and catch up eh.

I’ve been working on this same problem too. I submitted an Emacs
bug(#5434) and was given this explanation by one of the respondents:

,—-
|
| > Okay, I’ll try that, but a quick question: should an xauth problem result
| > in failures for every X application I try to run? Other applications
| > (other than emacsclient) run just fine.
|
| There is a difference. When you start other clients, you do it from
| the shell started by the ssh login process. When you do emacsclient
| -c it only tells your emacs daemon to open a frame on your DISPLAY.
| The emacs daemon is not started from your ssh shell.
|
| Try starting another X client from a shell not related to the ssh
| shell with the ssh-forwarded display (localhost:10) and see what you
| get. You should get permission denied. But your Emacs daemon may
| have other displays opened, that can influence matters also.
`—-

All my machines (two Fedora 12, one Ubuntu Karmic Koala) have the
newest gnome, and I confirm the same bizarre xauth locations as you
do.

I’m at least glad I’m not the only one!

Joel