Closed mviereck closed 3 years ago
I tried you above suggestion with --home --user=root --sudouser
, and meet the following error:
x11docker ERROR: Option --home: Could not create persistent home folder for
user 'root' on host. Can e.g. happen with option --user.
Four possibilities to solve issue:
1.) Run x11docker one time as user 'root'.
2.) Run x11docker one time as user 'root'.
3.) Use option --home=DIR with DIR pointing to a writeable folder.
4.) Use option --home=VOLUME to use a docker volume.
Very strange, in the above message, 1.) and 2.) are completely same.
Very strange, in the above message, 1.) and 2.) are completely same.
ok, hat looks a bit odd here. It would look different if you would run with another user name, e.g. --user=someoneelse
.
However, that is not related to the X authentication issue of this ticket but a special case of --home --user=root
.
I still can't figure out why x11docker prevent the use of the following two options at the same time:
--home --user=root
I still can't figure out why x11docker prevent the use of the following two options at the same time: --home --user=root
This would need access to HOME
of root, i.e. folder /root
on host. You would need to run x11docker as root to allow this, at least one time to let it create /root/.local/share/x11docker/IMAGENAME
. Your regular user werner
is not allowed to do this.
If running a container with
--sudouser
, running GUI applications withsu
orsudo
fails with an authentication error.DISPLAY
andXAUTHORITY
are set correctly. Running with--user=root
instead works fine.Workarounds found so far:
--sudouser --xoverip
--sudouser --hostnet
A message explaining the workarounds is shown if one uses
--sudouser
.I am not exactly sure why it does not work to run GUI applications with
sudo
, but--user=root
works. X has some sort of dbus authentication next to the classicXAUTHORITY
cookie method. This might explain why--xoverip
and--hostnet
can be used as a workaround. But this does not explain the different behaviour ofsudo
vs.--user=root
. For that case I would expect to fail--user=root
the same way likesudo
with--sudouser
does.