Perhaps there is the typo there? You mention that you get the different output when running id on the host, both times.
Oh sorry! I meant in the container I get uid = 1000(user) gid = 1000(user).
I have gid = 998(wheel) on the host.
I reconfigured from scratch and now I have shared folder working perfectly with raw.idmap both 1000 1000.
But even with Xauthority, raw.idmap (both) and path to X0 I still have no protocol specified.
I also tried with and without my shared folder mounted just in case.
I don’t understand what I miss…
I created this following minimal profile and it works for me.
$ lxc profile show guishared
config:
environment.DISPLAY: :0
raw.idmap: |
uid 1000 1000
gid 1000 1000
security.idmap.isolated: "true"
description: GUI LXD profile and shared folder
devices:
X0:
path: /tmp/.X11-unix/X0
source: /tmp/.X11-unix/X1
type: disk
mygpu:
type: gpu
mysharedfolder:
path: /LXDSHARED
source: /home/myusername/LXDSHARED
type: disk
name: guishared
used_by:
-
raw.idmap: both 1000 1000 should work for you, even if the group ID is different, because you get correct the UID. I have tried in my case to set a different GID and it worked.
Note that in any case, when you make changes in the profile, you need to restart the container so that the profiles are reapplied.
I dink that something goes wrong with the application of the idmap. You need to verify that the uid/gid that is received at the X11 socket on the host, is the uid/gid of your desktop user. But how to you verify that?
See https://shenaniganslabs.io/2019/05/21/LXD-LPE.html and create this Python file that creates a socket, and shows you the UID/GID of the process that opens this socket. By doing so, you will be able to verify conclusively the UID/GID of the container process that opens the socket. For this test, change temporary the X11 socket to echo.sock.
So I tried your minimal profile and shared folder is fine but I still have the same error about X0 not specified…
I changed it by /tmp/.X11-unix/X0 like your tuto on your blog because it does not find X1 on my system.
I also followed your advice with the python script and I’ve got:
Host : UID:1000, GID:998
Container : UID:0, GID:0
Wow I even follow this guide https://gist.github.com/stueja/447bd3bc0d510a0a7e50f9f1ef58ad75 step by step, straightforward and specifically design for arch and It does not work at all. It’s driving me nuts!
Are these copied and pasted? Because the script shows the output in a different format.
Also, how do you get this Container: line? Why do you get 0, 0? Do you run something as root?
Not copy pasted. I typed it.
The actual output of the script gives (for the host) PID: 1150, UID: 1000, GID:998 and (for the container) PID: 4035, UID:0, GID:0
I typed Host: and Container to make a difference between each other.
I really don’t know, when I saw the output from the container UID & GID :0 I was really surprised because I was logged in with my regular user and not using sudo with the nc -U command. And my container is an unprivileged one.
Hmmm, what command do you use to get a shell in the container?
As I’m not yet used to lxc exec… I use
lxc console container
then I log in with the regular user, that’s the reason I’m surprised that the output give me UID 0.
I managed to replicate the issue; indeed with lxc console mycontainer something is different and the X application does not start.
Here is the output
$ lxc console mycontainer
To detach from the console, press: <ctrl>+a q
Ubuntu 18.04.1 LTS mycontainer console
mycontainer login: ubuntu
Password: *************
ubuntu@mycontainer:~$ xclock
Error: Can't open display:
ubuntu@mycontainer:~$
Until I figure out what’s going on, you can follow the following guide,
and get the shell with
lxc ubuntu mycontainer
Well, still can’t open display :0
The container is ubuntu from repo, package x11-apps, mesa-utils installed, minimal profile you provide assigned and alias is set up. I made every step carrefully, restarted everything and still no protocol specified.
Is it possible that my arch box is the problem?
Otherwise if I do ls -l /tmp/.X11-unix/X0 command in the container I get user ubuntu and group nogroup. I’m wondering if it can cause issues?
lxc console gets you attached to a getty process spawned by PID 1.
PID 1 (systemd) ignores the environment variables we set for it and doesn’t propagate them down to its children. The result is that lxc exec BLAH bash will have all the environment.* keys respected while lxc console BLAH will not.
I tried to find some help on Arch forums, I did not find an answer about the socket not working but someone suggested me to try x11 forwarding over ssh instead. I’ll explore that…
Thanks @simos for your help and your tutorials.
ArchLinux has these extra steps to run unprivileged containers,
https://wiki.archlinux.org/index.php/Linux_Containers#Enable_support_to_run_unprivileged_containers_(optional)
I did follow these steps.
In the meantime X11 forwarding over ssh is a good alternative.
The fact is I’m wondering if it has to do with the installation of the distro. To be precise, I use to make base install without desktop env or extra packages, then I install the needed one.
Arch / debian base install (wihout desktop env pre-installed) I get the X0 error.
However, with a fully desktop env (xfce) installation on debian, it is working.
I tried installing Arch and the whole installation process is so involved. It just feels a shame to start with a trial installation but then not stick with it as your only distro until the end of times.
Also, these AUR packages do not have some official tool to build them. yaourt, which is discussed on the various forums, is now obsolete?
Have you seen the Arch image from osboxes? I’ll give it a go and see how it works.
So, I managed to make this work.
In summary, on Arch you are either required to run xhost +local: on the host, or create a suitable .Xauthority in the container. On top of the other instructions.
By running on the host xhost +local:, you allow local users to use your desktop’s X server.
You can later remove this right with xhost -local:.
The $XAUTHORITY file contains a cookie and the hostname of the computer that is allowed to make the connection. Which means that if you copy verbatim your host’s $XAUTHORITY to the container, it will not work (unless the container is also named the same as the host). Or, if you edit $XAUTHORITY to accept any hostname.
2 Likes
Ha excellent! I was gonna tell you the same thing thanks to an arch user.
But he said there are security implications using xhost -local: and I don’t fully understand why.
Also, this command does not persist after a reboot.
Yes indeed, that’s one of the reasons I find arch interesting. This distro force you to really understand how things are working.
You can use makepkg command to build them and use the regular package manager to remove them like pacman -Rs somepackage.
I did use Yaourt but it was a long time ago and as makepkg is straighforward and the need of package from AUR is occasional, I don’t see the point of using it anymore.