I have Debian, Sid if it matters, and I'd like to start X from the console, rather than using a display manager, but when i type startx <RET> I receive the following message

xinit: connection to X server lost

If I'm logged as root, or if I use sudo, I'm able to start X so I suspect that permissions are at the root of the problem .

What should I do to enable generic users to start X, possibly via startx ?

I'm interested both in a simple solution, achieved probably manipulating permissions, that has other drawbacks and in a possibly more complicated solution, maybe a proxy like a sort of non-graphical display manager, or whatever else…

  • Do you have just "regular" Debian Sid, or have you swapped things like the init system or custom ~/.xserverrc? I'm asking because unprivileged startx has, in fact, been working by default, for many years on stock Debian & Arch installs; if I remember correctly it was possible all the way back in 2008 and is still possible now. (Though the actual mechanism by which it works has changed during the init system switchover.) Aug 21, 2021 at 18:35
  • I have regular Debian Sid, and it's a long time (almost forever)I have not been able to use startx but I had to rely on a display manager.
    – gboffi
    Aug 21, 2021 at 19:55

3 Answers 3


It is possible the .xauthority and .ICEauthority files are owned by root. Attempt to remove them, or, in order not to break something, move them away:

sudo mv ~/.Xauthority ~/.bak.Xauthority
sudo mv ~/.ICEauthority ~/.bak.ICEauthority

It is recommended to perform this in a non-X environment, by switching to a virtual terminal using i.e. Ctrl + Alt + F2.

  • The files you mention are created from the X server before any error is issued and their user.group is correct (i.e., boffi.boffi). So no, thank you.
    – gboffi
    Aug 19, 2021 at 12:35

From this question ("Start X as a user other than root") and this answer, that references this article, I came up with the following solution

sudo chown $USER /dev/tty8
sudo chmod o+rw /dev/input/*
startx -- vt8 -retro -sharevts -logfile ~/.local/X.log &

The Xorg server is started correctly (?) but, all the possible security issues notwithstanding, a bunch of other issues follows, e.g.,

  1. some stuff typed in Chrome's search box ends up in the console that launched X together with a little amount of garbage,
  2. I'm unable to use the usual CtrlAltn sequence to switch to another terminal
  3. some clients that were provided automagically by the display manager are no longer present, most annoyingly the whatever it is that intercepts the uses of Multi Key and places the composed character on the bus(???), to be seen by Chrome that otherwise ignores X's compose sequences (very annoying, as I use a US kbd layout but I like to write, e.g., Barbora Krejčíková w/o copy&paste).

I'd like to hear, possibly in comments, about possible fixes to the aforementioned issues.


This has been possible by default for many years. Something on your system has made it no longer possible and the real question isn't "what mechanism to use to make it work" but rather "how to make the existing mechanism work again".

There are two different mechanisms which allow unprivileged startx usage:

  • Previously (pre-systemd), the X server /usr/bin/Xorg used to be setuid root. This was the traditional mechanism, especially when Xorg still used to do direct PCI access. Now Xorg itself is not setuid but comes with a setuid launcher "Xorg.wrap" which detects whether root rights should be retained or not.

  • Now, the systemd-logind daemon automatically grants permissions to the user corresponding to the foreground tty. This partially predates systemd, as udev + ConsoleKit already used to add the "foreground" user to various /dev ACLs even before that; however, systemd-logind additionally acts as a proxy for Xorg to access /dev/input without directly having rights there.

    On distributions which don't use systemd, the elogind daemon can do the same. On distributions which would like to avoid systemd at all costs, the seatd daemon may be used (although with a different API which Xorg doesn't yet support, as far as I know).

As Debian primarily uses systemd, you should have systemd-logind running, and your PAM configuration should invoke pam_systemd.so to register console logins with the daemon. When you log in at the console, loginctl session-status should report you as the active user on "seat0", and getfacl /dev/snd/pcm* should list you as having r/w access to audio devices.

(Note: You actually have to log in as the correct user. Logging in as root and using su -l <myuser> explicitly does not count – if you only do this then the session remains owned by root; device access rights will not be transferred when 'su' is used.)

When everything works correctly, Xorg will be able to directly open the GPU through /dev/dri, and will talk to systemd-logind through D-Bus to open devices in /dev/input; you should see this mentioned in your Xorg.0.log. (This uses the system bus, not a session bus – i.e. dbus.service and not dbus-launch.)

Do note that with systemd-logind or elogind, you should be starting Xorg on the same foreground VT, directly on top of your text-based login – not on a dedicated VT. This means using vt$(fgconsole) and not vt8 (though Debian's startx does the right thing by default).

In some situations (e.g. when using the proprietary nVidia GPU drivers without kernel modesetting support), systemd-logind's ACLs and proxying might not be enough and you'll still need to use a setuid Xorg. This can be enabled in /etc/X11/Xwrapper.config as documented in Xorg.wrap(1).

  • Your post is indeed informative, but is it propositive? I dare say no.
    – gboffi
    Aug 21, 2021 at 20:26
  • 1
    I propose that you go through the described mechanisms one by one and make sure that they work on your system as described, until you find one that doesn't, and fix it until it does. Aug 21, 2021 at 21:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .