GUI snaps can't connect to display in VNC

snapd
1

If I boot into the systemd multi-boot.target (instead of graphical.target), I can’t get the snap-store GUI to start under a VNC server (Xtigervnc). If I reboot into graphical.target, I can start snap-store both under the DM as well as the standalone vncserver. So, it seems like something snap-store is doing depends on the system being booted into graphical.target.

Maybe this can be resolved so that snap-store is usable on a headless system?

The only output I see from snap-store is this:

$ snap-store --verbose
No protocol specified
Unable to init server: Could not connect: Connection refused
17:32:59:0072 Gtk cannot open display: :1.0
2

What is the multi-boot.target you talk of?

3

Assuming you meant multi-user.target I was able to reproduce the issue you describe.

Interestingly it doesn’t seem to be related to confinement, as I installed the snap in devmode and got the same issue.

It’s not related to the systemd boot target, though. Booting into graphical.target, switching to the text console and logging in there and starting a vnc server ends with the same error.

It’s not just the snap-store snap, either: installing xbill-xaw you also get a “cannot open display”.

Something for @zyga-snapd to look into in the morning, perhaps.

4

Yes, sorry, I meant multi-user.target. Too many foreign concepts tumbling around in my brain!

1 Like
5

I’m seeing a similar issue on a headless machine running Ubuntu 20.04 Server. If a screen, keyboard and mouse are directly connected to the machine, snaps work fine, but over VNC they get the same error that kmksea mentioned. Any thoughts on how to fix?

6

Is the X server listening on an abstract namespace socket? That is, if you run the following command:

netstat -xlp | grep X11

Does it have an entry like @/tmp/.X11-unix/Xn (the leading @ is important, and the trailing n should match whatever display number is in $DISPLAY).

7

Thanks for the reply. Yes, the X server is listening on an abstract namespace socket. Any other thoughts on things to check?

8

Turns out that this is solved by doing

xhost +

before running the snap, but I’m worried about the security implications of this. Is there a more secure way to give snaps the proper permissions they need to access the X server?

9 
xhost +si:localuser:$USER

should be safer. It grants X11 access to all programs running under your user account only.

See the xhost manual page for details.