search

mviereck / x11docker

Run GUI applications and desktops in docker and podman containers. Focus on security.
MIT License
5.62k stars 378 forks source link

Unable to launch `nautilus` after exiting x11-docker firefox #313

Closed SimplicityGuy closed 3 years ago

SimplicityGuy commented 3 years ago

Environment: Debian 10 (buster), latest updates (to within a week), Gnome

On a fresh boot or login, I'm able to launch Nautilus (the file manager within Gnome) without issues. It's themed correctly (I use a dark theme natively). Upon launching Jess' awesome firefox x11-docker container, when I launch a new instance of Nautilus, it launches but is unthemed/set to the native white theme. It seems like it's running on the xrpa compositor.

When I exit the sandboxed firefox, I'm unable to launch Nautilus. Looking at /var/log/messages I see the following emitted:

nautilus[14536]: cannot open display: :113

I start Jess' firefox image as follows:

x11docker \
  --clipboard \
  --xpra \
  -- --tmpfs=/dev/shm -- \
  jess/firefox

I checked to see what my DISPLAY is set to both before and after running the sandboxed firefox, and it's set to :0. I don't know where it's being changed to :113.

Any idea how to:

  1. Prevent Nautilus from running in xpra while the sandboxed firefox is running.
  2. If (1) is not possible, how to restore Nautilus' DISPLAY to :0
mviereck commented 3 years ago

I checked to see what my DISPLAY is set to both before and after running the sandboxed firefox, and it's set to :0. I don't know where it's being changed to :113.

This seems to be a Gnome specific issue. I am not sure why this happens. As you've already figured out, DISPLAY is set correctly to:0, but nautilus does not regard it. I'd call that a Gnome/nautilus bug.

Somehow Gnome applications use the latest running X server instead of the one specified by DISPLAY. Though, this has been rarely reported and I got no response to my questions in earlier tickets.

As a workaround you could use x11docker option --hostdisplay to avoid additional X servers.

Can you reproduce the behaviour with running an X server yourself? E.g. run

Xvfb :50 &
sleep 2
nauilus

(Or try Xephyr instead of Xvfb to have a visible X server.)

Btw, do you use Gnome-Wayland or Gnome-X11? That might make a difference. You can check this with echo $XDG_SESSION_TYPE.

SimplicityGuy commented 3 years ago

Thanks for the reply. It very likely may be a Gnome Nautilus bug.

I tried running:

Xephyr :50 &
sleep 2
nautilus

I first had a blank X11 window show up from Xephyr, and then the Nautilus window showed up, with the proper theming.

I killed Xephyr (by closing the blank window), and closed Nautilus. I restarted Nautilus, and it again showed the window with proper theming as I would expect.

My XDG_SESSION_TYPE is wayland.

mviereck commented 3 years ago

I killed Xephyr (by closing the blank window), and closed Nautilus. I restarted Nautilus, and it again showed the window with proper theming as I would expect.

Odd. I wonder what makes the difference to an X server started by x11docker.

Could you please run further tests? Maybe xinit makes a difference (used internally by x11docker):

xinit -- /usr/bin/Xephyr :50 &
sleep 2
nautilus

Maybe the issue is specific to xpra, run x11docker with --xephyr instead:

x11docker --xephyr jess/firefox &
sleep 10
nautilus
SimplicityGuy commented 3 years ago

Ok, so I re-tired the initial steps since I had observed some different behavior later in the evening yesterday. Specifically, after locking my machine and unlocking, Nautilus no longer launched.

After retrying the initial steps a few times, it turns out my previous update was incorrect. In fact after Xephyr exits, Nautilus no longer displays. I suspect that the first time I ran the test I didn't wait until Xephyr exited completely.

As you originally suspected, I too believe that this is a Nautilus bug, capturing the last display used rather than pulling from the environment. I'm going to dig into this a bit on the Nautilus side before filing an issue there.

I appreciate the time you've spent digging into this with me!

SimplicityGuy commented 3 years ago

Filed an issue with Nautilus: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1707

mviereck commented 3 years ago

Thank you for filing the bug at gnome.org! I've installed Gnome here, too and tried to reproduce the issue with x11docker and Xephyr as well. I could not reproduce. However, I was not able to run a Gnome-Wayland session but an x11 session only (if that matters). You have Gnome 3.30.2. On my debian bullseye system I have:

$ gnome-shell --version
GNOME Shell 3.38.2

Maybe the bug is fixed indeed in recent Gnome versions.

mviereck commented 3 years ago

I wonder how to handle this issue now. Using --hostdisplay is a usable workaround, although I discourage this option otherwise. x11docker could print a warning if it finds Gnome<3.38.x. (Though, don' know exactly when the bug was fixed.) You could finally check if the issue happens in a Gnome-x11 session as well.

mviereck commented 3 years ago

x11docker now prints a warning if running Gnome <3.38 and defaults to option --hostdisplay in that case.

It would still be of interest if the issue occurs in a Gnome-Xorg session as well.

n-riesco commented 3 years ago

@mviereck To answer your question, I see this is issue in Ubuntu 20.04.2 LTS with Gnome 3.36.8 and both Wayland and Xorg.

mviereck commented 3 years ago

To answer your question, I see this is issue in Ubuntu 20.04.2 LTS with Gnome 3.36.8 and both Wayland and Xorg.

Thank you! Good to know it is not specific to a Wayland session.

Gnome 3.36.8

Still close to 3.38 where the issue is fixed.