I am trying to re-create functionality I’ve had for years; namely, installing an app, GIMP, on a remote server and running it remotely and seeing the graphical output locally, over ssh -X.
$ snap version
snap 2.44.1
snapd 2.44.1
series 16
ubuntu 18.04
kernel 5.3.0-46-generic
Before posting this I have, on the remote machine:
verified that /root is real (not a symlink, nor a bind to another directory)
(Note: I have to reveal this because of an earlier install issue I posted)
Then I logged in the customary way. % ssh -X remotehost
Note that other graphical apps work:
% xeyes
% qgis
[both work, meaning output visible on localhost]
But not:
% gimp
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf-8)
X11 connection rejected because of wrong authentication.
Cannot open display:
However, the DISPLAY variable has been set (presumably by ssh, to send it back to the logging-in host):
$ env|grep DISPLAY
DISPLAY=localhost:10.0
What more may I check?
Thank you.
[Incidentally, I have edited this post a few times trying to get the remaining cmdlines and responses to be “Preformatted Text” but the editor is ignoring the codes in the Preview while showing them in the Composer.]
I think you’ve found a deficiency in the X11 interface This is a bug that should be fixed in snapd. @jdstrand, I think this one is for you. The current X11 interface probably doesn’t account for remote X11 sockets.
I found and followed this, rebooted and got the same result:
But don’t need to go there, here’s the conclusion which is what I implemented (exc. in /etc/ssh/sshd_config because /etc/opt/ssh doesn’t exist in my Ubuntu 18.04 install):
Oracle (internal) support came back with a fix that worked
"set X11UseLocalhost variable to 'no' in the file /etc/opt/ssh/sshd_config"
Probably SSHD daemon needs to be restarted.
I added the line: “X11UseLocalhost no” to /etc/ssh/sshd_config and rebooted to restart sshd although if you’re watching, you could do this with
% sudo service ssh restart
or
% /etc/init.d/ssh restart
Any update on this? I just upgraded my Ubuntu server, and have completely lost the ability to test our code. I need to get chromedriver working in due course, but even running the chromium-browser is not possible with the snap. LIke @DavidOertl, I’ve followed the various guides on ensuring SSH Forwarding is working, and all other apps are fine.
I know this is Open Source and all, but I’m completely dead in the water so help really appreciated.
Thanks, Shaheed
P.S. I had previously held off using the snap until I got my $HOME-is-not-under-home, but I have the needed bind mount in place now. Pending that, I was able to replace the snap with pre-snap chromium-xxx, but that is now broken with some seemingly hard-coded snap dependency; if there is a way to revert that would get me going, I’d appreciate that too.
Yes, assuming this is on amd64, the syscall in question is ‘uname’ and their seccomp sandbox needs to be updated to allow it, or the thing that is calling uname should not do that.
That said, what is the apparmor denial from journalctl that corresponds to that AccessDenied dbus failure? It is possible that it is the denial that is triggering error handling code (which calls uname).
Thanks, but after a good deal of scratching around, it seems that over time, this is/has been a known problem for chromium. There are reports of issues like this going back (on-and-off) for years…
This is a bug that should be fixed in snapd.