When I try to start X with i3 by typing startx /usr/bin/i3 I get the following error message: (EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied)

Launching startx as root or after chowning /dev/tty7 solves it (expect for input not working, not even switching terminals), but I don`t think that is the proper way to do that.

Sway and Weston work flawlessly why won`t X do so?

  • have you somehow compiled Xorg without support for logind? Might be tagged as systemd support, not logind specifically. Wiki doesn't seem to show a USE flag for it though.
    – sourcejedi
    Jan 28, 2019 at 15:53
  • I did not no that when I log into a terminal the corresponding /dev/tty* device becomes owned by my user. Now X starts properly. (expect for the input, but I guess for that I have to ask a new question)
    – xuwenbuwer
    Jan 28, 2019 at 16:10
  • new question sounds good, to provide all your information about the input devices (error messages? log doesn't mention any input devices at all?). Remember to mention how well Weston worked in comparison. I would also be interested in loginctl seat-status seat0. Successful output from loginctl seat-status is long, but you can at least say if it list any input devices or not.
    – sourcejedi
    Jan 28, 2019 at 16:47
  • 1
    I just had to install x11-drivers/xf86-input-edev for the input, now i3 works perfectly.
    – xuwenbuwer
    Jan 28, 2019 at 16:52
  • 1
    Sorry for not saying this earlier: Users have asked me to provide more feedback. I would upvote this question, except I don't like to upvote them when they don't include any version numbers. On other OS's, I often accept the overall OS version number. But that's not possible since Gentoo is a rolling release. No pressure, but to use this as an example, if you want my upvote you would include the version of Xorg package that had this problem. Ideally also the version of the Weston or Sway package that worked.
    – sourcejedi
    Feb 2, 2019 at 17:19

2 Answers 2


startx works fine on my system (Fedora). However, one outdated page on the Gentoo Wiki mentions a different way to run it:

startx /usr/bin/i3 -- vt1

1 is the number of the "terminal" you are logged in on. If you are not on terminal 1, then adjust the command accordingly.

Apparently this fixed the Permission denied error, and allowed X to start.

I don't understand why startx would need this to be passed explicitly. I don't understand how Gentoo could be doing anything differently to Fedora here. Oh well. At least it should stop startx / Xorg from trying to open tty7. That was definitely not the modern way to do things, and it was not working for you.


Cannot open virtual console (Permission denied) can also be caused by a permission issue on /dev/ttyX.

For instance on my openSUSE MicroOS before login:

$ ls -l /dev/tty1
crw--w---- 1 root tty /dev/tty1

but after login:

$ ls -l /dev/tty1
c--xr-xr-T 1 $USER tty /dev/tty1

The login utility is changing the owner of the TTY so you can type into it. However in this case, it is also changing the permissions and read-write are no longer permitted! Thus, startx shows the permission denied error because it can't write on the device.


Change permission of the TTY before startx. In my .zprofile:

# Auto-start Xorg when logging in on TTY1
check_tty() {
    local temp=$(tty)
    echo ${temp:5}

if [ $(check_tty) = "tty1" ]; then
    chmod 1600 /dev/tty1              # Notice the permission change before startx
    exec startx

Possible cause

I could not find the exact cause of the issue. It might be linked to systemd-logind as I also have the same ownership problem as this report and this one when startx fails.

I also investigated PAM and udev but nothing seems to change the /dev/tty mode to 1155 while it is happening in practice!

You must log in to answer this question.

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