Unprivileged xinit wont start in unallocated vt

[Adam M]

If as an unprivileged user you launch xinit (or startx) to any vt (EVEN IF UNALLOCATED BY SYSTEMD) it will fail as described below. The only exception appears to be if the vt you attempt to launch X onto is already logged into by that user. For many this makes running X unprivileged unworkable.

--

When attempting to run xinit or startx after upgrading from 14.04 to 16.04 it will not work. There seems to be some sort of permission issue. I have seen another person with this issue as well here:

http://askubuntu.com/questions/749370/ubuntu-16-04-xf86openconsole-cannot-open-virtual-console-2?newreg=ba376d7a182d44608ed4675346b1ed74

An example is when attempting to launch kodi, which worked prior to the upgrade:

xinit /usr/bin/kodi --standalone -- -nocursor :0

X.Org X Server 1.18.1
Release Date: 2016-02-08
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.13.0-79-generic x86_64 Ubuntu
Current Operating System: Linux hostname 4.4.0-15-generic #31-Ubuntu SMP Fri Mar 18 19:08:31 UTC 2016 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-15-generic root=UUID=6f2e8267-1240-4f7b-9889-42e65d74767e ro biosdevname=0 text
Build Date: 11 March 2016 07:43:21AM
xorg-server 2:1.18.1-1ubuntu4 (For technical support please see http://www.ubuntu.com/support)
Current version of pixman: 0.33.6
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/arch/.local/share/xorg/Xorg.0.log", Time: Fri Mar 25 20:14:07 2016
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE)
Fatal server error:
(EE) xf86OpenConsole: Cannot open virtual console 2 (Permission denied)
(EE)
(EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
(EE) Please also check the log file at "/home/arch/.local/share/xorg/Xorg.0.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused

I have tried numerous workarounds including reinstalling xorg, removing all x-related files in my profile, and creating a new user. Unfortunately none of these worked.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: xinit 1.3.4-3
ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6
Uname: Linux 4.4.0-15-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
Date: Fri Mar 25 20:14:18 2016
DistUpgraded: 2016-03-25 09:16:37,728 DEBUG enabling apt cron job
DistroCodename: xenial
DistroVariant: ubuntu
DkmsStatus: oem-audio-hda-daily, 0.201412181801~ubuntu14.04.1, 3.13.0-83-generic, x86_64: installed
EcryptfsInUse: Yes
ExecutablePath: /usr/bin/xinit
GraphicsCard:
 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0402] (rev 06) (prog-if 00 [VGA controller])
   Subsystem: ASRock Incorporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [1849:0402]
InstallationDate: Installed on 2014-12-14 (467 days ago)
InstallationMedia: Ubuntu-Server 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.3)
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-15-generic root=UUID=6f2e8267-1240-4f7b-9889-42e65d74767e ro biosdevname=0 text
SourcePackage: xinit
UpgradeStatus: Upgraded to xenial on 2016-03-25 (0 days ago)
dmi.bios.date: 05/18/2015
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P1.90
dmi.board.name: H97M Pro4
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.90:bd05/18/2015:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnH97MPro4:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.
version.compiz: compiz N/A
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.67-1
version.libgl1-mesa-dri: libgl1-mesa-dri 11.1.2-1ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 11.1.2-1ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.18.1-1ubuntu4
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.6.1-1ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20160218-1ubuntu3
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12-1build2
xserver.bootTime: Fri Mar 25 19:47:54 2016
xserver.configfile: default
xserver.devices:
 input Power Button KEYBOARD, id 6
 input Video Bus KEYBOARD, id 7
 input Power Button KEYBOARD, id 8
 input Sleep Button KEYBOARD, id 9
 input AT Translated Set 2 keyboard KEYBOARD, id 10
xserver.errors:

xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 product id 2223
 vendor ACR
xserver.version: 2:1.18.1-1ubuntu4

[Adam M (zambien1977)]

Any update on this?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Stanislav Yadykin (tosick)]

«sudo chmod 0660 /dev/tty*» worked for me until reboot. Changing permission in udev rules for tty to 0660 from 0620 could be a temporary fix.

[Bram Roets (bram-roets)]

I'm having the same problem. Is their any fix yet available ?

[Adam M (zambien1977)]

There is a workaround. See:

http://kodi.wiki/view/HOW-TO:Autostart_Kodi_for_Linux

Specifically:

5 Add a new systemd script

And everything under it.

[Mikkel Kromann (w-mikkel)]

I am affected by the same bug, although the X error message is slightly different ("parse_vt_settings: Cannot open /dev/tty0" instead of "xf86OpenConsole: " ...)

In /etc/X11/Xwrapper.config I have tried to replaced

allowed_users=console

with

allowed_users=anybody

and in this file I also tried the option

need_root_rights = yes

but both attempts had no visible consequences.

I have looked at the workaround for koda posted above, but I am unable to extract the bits that may make it help in my case. Perhaps someone can give suggestions to me based on the posted workaround. The program I want to run in its own Xserver is a game, so all the systemd stuff in the workaround is not that relevant to me. Although my knowledge of X is very limited, I'd love to contribute with some testing as far as I can go. Thanks for your time and efforts /Mikkel.

mikr@scrat:~/bin$ xinit /home/mikr/bin/WoWrun64 -- :1 -br
X.Org X Server 1.18.3
Release Date: 2016-04-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.13.0-86-generic x86_64 Ubuntu
Current Operating System: Linux scrat 4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 2016 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-24-generic root=UUID=1346e355-5120-4563-9e27-28d965d357f4 ro quiet splash
Build Date: 18 May 2016 01:07:07AM
xorg-server 2:1.18.3-1ubuntu2.2 (For technical support please see http://www.ubuntu.com/support)
Current version of pixman: 0.33.6
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/mikr/.local/share/xorg/Xorg.1.log", Time: Fri Jun 24 19:10:21 2016
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE)
Fatal server error:
(EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or directory)
(EE)
(EE)
Please consult the The X.Org Foundation support
  at http://wiki.x.org
 for help.
(EE) Please also check the log file at "/home/mikr/.local/share/xorg/Xorg.1.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

[Mikkel Kromann (w-mikkel)]

Hi again.

Seems that my case is connected to my NVIDIA card and this bug:

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1525735

The following solved my problem:

sudo apt install xserver-xorg-legacy

In /etc/X11/Xwrapper.config I replaced

allowed_users=console

with

allowed_users=anybody

[Konstantin (hi-angel-z)]

None of workarounds worked for me.

Omg, is there a single thing which 14.04 → 16.04 upgrade didn't break? Sad to see that distro widely recommended for newbies slowly drowns under a bunch of architectural, planning, and software problems, which are hard to fight even for long time users. Perhaps since now we should recommend Fedora instead.

[Aaron Peromsik (aperomsik)]

Two relevant-looking Fedora patches which I haven't tried yet:

http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-server.git/commit/?h=f22&id=943ff7334233f04fc2311945822cac537673a493

http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-server.git/commit/?h=f22&id=9d0fee062d4fbc0bee08db4fb8461c3d7f9ee0f5

related to this bug https://bugzilla.redhat.com/show_bug.cgi?id=1203780

[Aaron Peromsik (aperomsik)]

Never mind: if I am reading correctly it seems those commits I mentioned in #10 are already included upstream and in Ubuntu as well.

[Yuan Song (ysong)]

I found a simple solution for this issue. Start x server as root and then start windows manager as regular user.

1. sudo Xorg &
2. export DISPLAY=:0.0
3. bash .xinitrc

[Jay R. Wren (evarlast)]

another workaround:

setfacl -m u:kodi:rw /dev/tty0 /dev/tty7

[kloszard (kloszard)]

I don't know if it is real workaround but if you want to avoid running X as root you can

1. Go to one of tty1-tty6 and login as a normal user
2. run the server in the same tty you logged in, e.g. for tty6:

xinit /usr/bin/openbox -- :1 vt6

Tested on ubuntu mate 16.04.

[hackeron (hackeron)]

The workaround is not working :( -

$ sudo setfacl -m u:kodi:rw /dev/tty0 /dev/tty7
setfacl: Option -m: Invalid argument near character 3
$ sudo chmod 0660 /dev/tty*
$
$ startx
...
Fatal server error:
(EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or directory)
...

Any ideas?

[Amro Khaled (amrography)]

try sudo stratx

[Chris (forever++)]

I've tried for an hour, but can't seem to get any fix working. Highly frustrating as I just switched my laptop from Debian to Ubuntu, and now I have to spend time switching it back again.

Comment #16 seems to misunderstand the bug. Likewise the workaround in comment #12 might possibly work for some people, but there appear to be several of us who rely on running X as a non-root user.

This is not something that I would have expected to be broken. Is there any update on this? It's been a while since anyone commented on it, and the bug doesn't appear to be assigned to anyone.

[Chris (forever++)]

I can confirm that #14 works for me also, however it doesn't provide me with with the functionality that I require.

It would be useful to know whether this is intended behavior, or an unintended bug.

Updated bug title to reflect comment #14, and added a paragraph to the top of the bug description outlining the issue as it is currently understood.

[Ubfan (ubfan1)]

Ubuntu 16.04, Nvidia Quadro 1000m, #14 allow the X server to run, applications may be launched (xterm, then xclock) and they appear in ps, keyboard input to the xterm works, but the display is totally black. No errors are in the ~/.local/share/xorg/Xorg.1.log file (a failure does show:
xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
but that appears in the working :0 display log also. Running as root has same result, black display on the vt. There may be several issues here.

[Ubfan (ubfan1)]

On another 16.04 machine without Nvidia, comment 14 produced a working display. The Nvidia driver causing the problem on the first machine was 367.57.

[Ubfan (ubfan1)]

Comment 14 works with Nvidia when using the nouveau driver, but not the Nvidia driver 367.57 (black screen). Starting an xterm allows you to run other things, even unity.
Using the nouveau driver, login to vt2 and run:
xinit /usr/bin/xterm -- :1 vt2
Result is a white background xterm, fully functional when cursor is over it.

[Chris (forever++)]

Ubfan1's comments (#19, #20 and #21) are not relevant to the bug as it has been described. We were already aware that X sessions could be started on the same vt as the command line that they're launched from.

Further complications from the Nvidia driver would seem to be a separate bug?

As the bug forces X to be run with escalated privileges, I would categorise it as a SECURITY bug (which would raise it's BUG HEAT score). However I am not aware of how this is accomplished. I hope that someone will review and comment on this suggestion.

[My name (plmalternate)]

Me too. Under 16.04, 64 bit, with openbox, startx (or xinit) as user fails. Sudo startx gives me a console with a tiny font, so apparently it starts X but not Openbox. I'd explore that further and probably find how to start Openbox, but I don't want to run X as root anyway. I just tried sudo as a diagnostic experiment.

I have another 16.04 64 bit system on the same machine using lighdm. That does boot and run openbox. That sys has OTHER problems I won't go into here, but it does prove the problem lies with xinit. Given all the OTHER problems with it, it also proves that 16.04 wasn't ready for release at all, let alone as an LTS. Maybe Canonical needs to reconsider the release-on-schedule policy and instead wait until they get through the alpha stage.

[My name (plmalternate)]

I should add that this probably the 5th or 6th time I've installed a 16.04 system on this machine and failed to get startx to work properly. I have another such that I haven't scrapped yet that WILL eventually start openbox in response to startx. But it takes a long time and results in my being logged in on ALL available ttys with most of them showing error messages about xserver failure.

[My name (plmalternate)]

Uh, I wish I could edit my 2 posts above out. My problem was simple. After installing from the mini.iso, I was running an installation script that has a command of the form:

sudo apt-get install --no-install-recommends package1 package2 package3 . . .

It always worked before. But one of those packages no longer exists and apparently apt-get just doesn't anything on a list like that when ANY of them are missing. There was an error message but it only refered to the one package so I falsly assumed it was getting the others. So I didn't have openbox. Duh.

[kloszard (kloszard)]

As for my post #14,

1) It was tested on Intel HD Graphics 3000 (only open-source drivers are available for this hardware)

2) One should launch a separate dbus instance when starting X. Without it, steam client, especially in big picture, mode stutters:

xinit /usr/bin/dbus-launch --exit-with-session /usr/bin/openbox-session -- :1 vt6

If I could edit posts, I would add this information on September. Sorry folks.

3) I've tested it also on proprietary Nvidia drivers (367.57) on my desktop (only few minutes). It seems the same issue is here; without dbus-launch instance, steam client in big picture works improperly. With the dbus, it seems to work flawlessly.

[Alan Dacey Sr. (grokit)]

This bug drove me batty until I found this. Making a Nextcloud appliance with Ubuntu Server 16.04 as the OS and I couldn't install a gui. Tried xfce, lxde, and lxqt to no avail. Re-installed, tried again, and nothing.
Post #14 worked for me but a little different.

startxfce4 -- :1 vt1

Is the proper command to launch xfce once logged on.

[StevenD57 (tevend)]

The workaround I used to fix the original problem as stated by the person who opened this ticket was to do the following:

chmod ug+s /usr/lib/xorg/Xorg

It seems in Ubuntu 14.04 the Xorg xserver binary has permissions of:

-rwsr-sr-x 1 root root 10192 Dec 9 2014 /usr/bin/X

so by running the above chmod command on the 16.10 (what I have installed) installed xserver binary does indeed fix the original poster's issue.

[Timo Aaltonen (tjaalton)]

no, the workaround should be to install xserver-xorg-legacy, which installs the suid-root wrapper again

[rebroad (rebroad)]

Does install the suid-root wrapper allow for any user to run an X server? This seems a little too open if so, as it seems better to allow only either root, or the user logged into the console to run the server, IMHO.

[Toni Melisma (tonimelisma)]

I opened up https://bugs.launchpad.net/ubuntu/+source/xinit/+bug/1876119 which is a duplicate of this bug.

We are celebrating the fourth anniversary of this bug. Perhaps xinit should be removed from Ubuntu if it's not a maintained package anymore?

This bug is still affecting me on latest 20.04 distribution. I have tried the following workarounds

- Setuid root for /usr/bin/Xorg (or setgid)
- Adding user to tty group
- Logging in to tty1 with the same user I start the X session with
- chmod 666 /dev/tty1

None of these work.

The only option that works is installing xserver-xorg-legacy and configuring /etc/X11/Xwrapper.config as follows:

allowed_users=anybody
needs_root_rights=yes

The only option

[FabricioFC (fabricfc)]

Check the /etc/xdg permissions (if not unusual, check other etc directories).

A "kid induced power shortage" (daughter :D) broken the directory's permissions (random numbers instead of "drwxr-x---").

After "sudo chmod -R 755 /etc/xdg", everything worked getting a rid of the msg "xf86OpenConsole: Cannot open virtual console 2 (Permission denied)"

Hope this helps

[Toni Melisma (tonimelisma)]

That does not help. Absolutely do NOT run "chmod -R 755 /etc/xdg" as this will set the execution bit on any files in that directory or subdirectories, that's completely incorrect.