I have a bug where permissions on /dev/input/event* are wrong, so when I use Mumble, the application can't detect key presses. If I run the following command it "fixes" the issue, but I'd like a permanent fix.

sudo chmod a+r /dev/input/event/*

What determines the permissions on /dev/input/event* and how do I permanently set them?

  • 6
    Note that if you give "all" permission to read /dev/input/event/* then you're essentially giving everyone access to sniff your keyboard, for example passwords that you type. On a single-user system this might not matter so much, but even on a single-user system we generally use system users as an extra layer of safety in case some component gets compromised, and by giving for example the nobody user access to your keyboard input stream you are weakening this protection. While this might "fix" Mumble, it isn't an appropriate general solution to your problem. There should be a better way. Apr 13, 2015 at 23:22
  • 3
    @popey Can you say more about why permissions on nodes in /dev/input are wrong, and what the ownership and permissions currently are (perhaps with the output of ls -l)? Is the problem that the input group doesn't have read permissions (or that it is not the group owner)? On my system the event files have root:input ownership and both the user and group owners can read from them. If you don't have this, you should perhaps try to set it up that way rather than letting everyone read them. If you do have this, it may be enough for Mumble to run with the powers of the input group. Apr 14, 2015 at 1:08
  • @EliahKagan what do you think of my answer ? can you please review it ? Apr 14, 2015 at 2:28
  • yes that's bad. use ACL. see my answer below
    – solsTiCe
    Apr 15, 2015 at 17:32
  • Can you let me know the Distribution version or xorg-server version ? because xorg-server 2: had solved the issue. Apr 16, 2015 at 16:20

5 Answers 5


A more flexible way to manage permission on files is to use ACL.

sudo setfacl -m u:popey:rw /dev/input/eventx

If you really need to make this permanent then you can use an udev rules that set it for your event input device

add a file /etc/udev/rules.d/99-userdev-input.rules with:

KERNEL=="event*", SUBSYSTEM=="input", RUN+="/usr/bin/setfacl -m u:popey:rw $env{DEVNAME}"

you can check the ACLs permission with

getfacl /dev/input/event*

I don't know what initially sets the permissions of the character devices /dev/input/event*

but, I do know you can change those permissions with a software which is on your system by default as part of coreutils. see the command man mknod.

The permissions of my event devices are:

crw-rw---- 1 root input 13, 64 Apr 14 06:39 /dev/input/event0

here are some usage examples:

~$ sudo mknod lolwat c 4 64 
~$ sudo mknod lolwatnow c 4 64  -m 777
~$ ls -l lolwat*
crw-r--r-- 1 root root 4, 64 Apr 14 08:07 lolwat
crwxrwxrwx 1 root root 4, 64 Apr 14 08:08 lolwatnow

if you need more info about for deciding on major and minor numbers, look here

Now, you say the permissions are wrong. So something must be setting them wrong, and that thing, must run as root. mknod could be used to create an device, but mkdev could also. you may want to look at the permissions of whatever the default actions are for mkdev, and mknod.

As in my examples: /dev/input/event0 has crw-rw permissions, but the default permissions, of lolwat were set to crw-r--r--

I have some uncertainty, whether type of device dictates original permissions.You can experiment with this to find out.

Here is another link for more info about mknod

  • is mumble running as root?
    – j0h
    Apr 14, 2015 at 13:52

Basically, you'd need to add a file in /etc/udev/rules.d/ (you could name it something like 75-input-events.conf)

And add lines KERNEL=="eventX" , SUBSYSTEM=="input", MODE="0777" for each event into that file, where x is the number. For instance, I have events 0 through 9, so I personally would do for each one of them. Last answer on this thread suggest you could have added KERNEL==event* (i.e., with wild card),too.


My suggestion is that you install the application input-utils

sudo -i
apt-get update
apt-get install input-utils

This is a collection of utilities which are useful when working with the input layer of the Linux kernel (version 2.6 and later). Included are utilities to list the input devices known to the kernel, show the input events that are received by a device, and query or modify keyboard maps.

The command of interest is:

sudo -i 

It dumps out all the input devices and the associated details about the device.

One can observe input events using the command, by specifing the Nth device number:

sudo -i
input-events <device number>

One can then dump out the keyboard mapping of a particular event device using the command ,by specifing the Nth device number:

sudo -i
input-kyb <device number>

With these tools one can debug a system to see if inputs generate the expected event codes and hence help sort out issues such as why keys don't work or are mapped incorrectly.

Udev is the device manager for the Linux kernel. It manages device nodes in /dev and handles all user space actions when adding or removing devices.

Evdev is a generic input event interface in the Linux kernel.It generalizes raw input events from device drivers and makes them available through character devices in the /dev/input/ directory.

Every time a change happens within the device structure, the kernel emits a uevent which gets picked up by udev. udev then follows the rules as declared in the /etc/udev/rules.d, /run/udev/rules.d and /lib/udev/rules.d directories.

Based on the information contained within the uevent, it finds the rule or rules it needs to trigger and performs the required actions.

These actions can be creating or deleting device files, but can also trigger the loading of particular firmware files into kernel memory.


In a terminal run:

sudo nano -b /etc/rc.local

Go down to the line that says "exit 0" and in a line above it type:

sudo chmod a+r /dev/input/event

Hit Ctrl+x to exit that. It will ask you if you want to save. Hit y. It will ask you what to save as. Just hit Enter.

Now, that command should start up at every boot and thus give you permissions to that folder. The /etc/rc.local file automatically has root privileges so you won't need to enter a password to do this.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.