Can't forward some X applications to Mac

[Cubytus]

Hi there,

I am pretty sure this topic has been dealt with before, but all solutions I could read on the Internet failed.
My current setup is a Raspberry Pi with NoIR, running the latest Raspbian, and a Mac having XQuartz 2.7.7.

I usually access the Pi with the command

Code: Select all

$ ssh pi@raspberrypi.local -Y

and invariably get this warning on connection:

Code: Select all

Warning: No xauth data; using fake authentication data for X11 forwarding.

Now, I can call some X applications such as midori, and it displays right in XQuartz, but calling GParted fails, maybe in a telltale way:

Code: Select all

$ gparted

brings up a warning through XQuartz saying that I need root privileges.
And calling

Code: Select all

$ sudo gparted

gives

Code: Select all

X11 connection rejected because of wrong authentication.

(gpartedbin:3187): Gtk-WARNING **: cannot open display: localhost:10.0

First, I don't know if the problem comes from Raspbian or the Mac.
References read:
http://dvisagie.blogspot.ca/2012/08/fix ... x-108.html Only deals with the issue between Macs, but not Linux. Paths are different.
http://unix.stackexchange.com/questions ... -data?rq=1 Lacks details on proper locally-forwarded connection. Adding pi@ to the Pi address, and user1@ to the Mac one failed to work.
http://serverfault.com/questions/422908 ... n-data-for None of the proposed solutions worked.

Any ideas how to tackle this pesky issue?

[jojopi]

$ ssh pi@raspberrypi.local -Y
Warning: No xauth data; using fake authentication data for X11 forwarding.

$ sudo gparted
X11 connection rejected because of wrong authentication.

I am not sure if the first message is normal for a Mac or not.

The second message is because SSH puts the authentication cookie for localhost:10 in /home/pi/.Xauthority, but under sudo, gparted is looking in /root/.Xauthority. You can manually set an environment variable to override the location: "sudo XAUTHORITY=~/.Xauthority gparted".

The much easier solution is to type "gksudo gparted" instead.

[Cancelor]

What does the -Y do, will it work without it?

Can you connect using

Code: Select all

ssh pi@192.168.1.xxx

or what ever the IP of the RPi is.

Can you add the RPi as a known host?

Code: Select all

ssh-keygen -f "/home/xxx/.ssh/known_hosts" -R 192.168.1.xxx

[AndyD]

What does the -Y do, will it work without it?

The -Y option enables trusted X11 forwarding. If you don't specify that you want X11 forwarding, then you can't forward X11 clients. By default ssh doesn't forward X11.

[Cubytus]

The Pi was automatically added as a known host when first connecting it through the Mac.

command

Code: Select all

$ gksudo gparted

works (thanks), but here is the result of

Code: Select all

$ sudo XAUTHORITY=~/.Xauthority gparted
======================
libparted : 2.3
======================
The program 'gpartedbin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 170 error_code 2 request_code 132 minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

However I'd like to use the Pi through an SSH connection exactly as I would in a local terminal.

How would that be possible? I'd like to avoid linking to a hardcoded IP, as I am also making some OS changes on the router and numerical IPs are not necessarily the same.

[jojopi]

I doubt the crash is related to the method of starting; there should not be a substantive difference between setting environment variables manually and letting gksudo do it.

Most likely it is an intermittent bug or race condition, or a minor incompatibility between gparted and the Mac OS X Server. If it is reproduceable then try "xdpyinfo -queryExt |grep opcode" to work out which extension is opcode 132, and then see if that extension can be disabled in gparted.

In many cases, you will need to use gksudo to start GUI applications as other users, even on the local display. The problem is more to do with the sudo environment and permissions than with SSH.

It makes zero difference to anything whether you connect by IP or host name.

[Cubytus]

It's easily reproduceable, with a 100% success rate. BTW, don't use the moniker "Mac OS X Server" as it usually refers to the Server version of OS X, not the X display server, and will surely lead to confusion.

As for the command,

Code: Select all

 $ xdpyinfo -queryExt | grep opcode
    Apple-DRI  (opcode: 128, base event: 64, base error: 128)
    Apple-WM  (opcode: 129, base event: 68, base error: 130)
    BIG-REQUESTS  (opcode: 134)
    DAMAGE  (opcode: 144, base event: 98, base error: 155)
    DOUBLE-BUFFER  (opcode: 146, base error: 156)
    GLX  (opcode: 150, base event: 102, base error: 160)
    Generic Event Extension  (opcode: 130)
    MIT-SCREEN-SAVER  (opcode: 145, base event: 99)
    MIT-SHM  (opcode: 132, base event: 72, base error: 132)
    Present  (opcode: 147)
    RANDR  (opcode: 142, base event: 96, base error: 151)
    RENDER  (opcode: 141, base error: 146)
    SECURITY  (opcode: 138, base event: 93, base error: 142)
    SGI-GLX  (opcode: 150, base event: 102, base error: 160)
    SHAPE  (opcode: 131, base event: 71)
    SYNC  (opcode: 135, base event: 90, base error: 138)
    X-Resource  (opcode: 148)
    XC-MISC  (opcode: 137)
    XFIXES  (opcode: 140, base event: 94, base error: 144)
    XINERAMA  (opcode: 139)
    XINERAMA  (opcode: 139)
    XInputExtension  (opcode: 133, base event: 73, base error: 133)
    XKEYBOARD  (opcode: 136, base event: 92, base error: 141)
    XVideo  (opcode: 149, base event: 100, base error: 157)

It refers to MIT-SHM, but what is that?