# -bash: /dev/null: Permission denied

I'm trying to create a new user on a Centos 6 system.

First, I do

useradd kevin


Then, I tried to run commands as that user

su - kevin


However, I get the following error messages

-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
[kevin@gazelle ~]\$


And I can't do very much as that user.

The permissions on /dev/null are as follows:

-rwxr-xr-x  1 root root           9 Jul 25 17:07 null


Roughly the same as they are on my Mac,

crw-rw-rw-   1 root   wheel         3,   2 Jul 25 14:08 null


It's possible, but really unlikely, that I touched dev.

As the root user, I tried adding kevin to the root group:

usermod -a -G root kevin


However I still am getting /dev/null permission denied errors.

Why can't the new user write to /dev/null? What groups should the new user be a part of? Am I not impersonating the user correctly? Is there a beginners guide to setting up users/permissions on Linux?

Thanks, Kevin

• Looks like /dev/null got changed to a 9-byte-long ordinary file; it's supposed to be a device file ('c' at the beginning of the file type/permission bits field). If you cat /dev/null, does it look like something you recently used? – Mark Plotnick Jul 25 '14 at 21:18
• ah. yes it did. "* master". do you want to add that as the answer & I'll mark it? – Kevin Burke Jul 25 '14 at 21:19
• You can reboot and /dev/null will get remade, but do you know what happened to change /dev/null into a file? It'd be a pain if it happened again. – Mark Plotnick Jul 25 '14 at 21:22
• My guess is I moved the output of "git branch" to /dev/null instead of writing it, or had a bad script or something – Kevin Burke Jul 25 '14 at 21:23

Someone evidently moved a regular file to /dev/null. Rebooting will recreate it, or do

rm -f /dev/null; mknod -m 666 /dev/null c 1 3


As @Flow has noted in a comment, you must be root to do this.

This should fix the issue (as root):

rm /dev/null
mknod /dev/null c 1 3
chmod 666 /dev/null

• This one also works on Mac/BSD – redolent Feb 11 '15 at 23:06

The solution suggested by Mark did not work on OpenBSD. However

mknod -m 666 /dev/null -c 2 2


did the trick. I have tested this on OpenBSD 5.6. When the accepted answer is executed /dev/null will block and screw any code reading from it pretty badly.

• Didn't the OP use CentOS rather than OpenBSD? – ott-- Mar 15 '15 at 18:23
• Unfortunately, different operating systems use different major/minor numbers for /dev/null, and there's no standard. OP asked about CentOS 6. Linux has used 1,3 for /dev/null going back to at least 2001. On FreeBSD, I've seen 0,6, 15,0, 17,0, and 20,0. OpenBSD uses 2,2. On OpenBSD, you actually don't need to know the numbers; you can run # cd /dev; ./MAKEDEV std . – Mark Plotnick Mar 16 '15 at 21:54
• Major and minor numbers are not transportable between operating systems. What works on Linux won't usually work on *BSD or Mac OS X (or Solaris, AIX, HP-UX, …), and vice versa. You have to find the correct numbers to use in the mknod command by scrutiny of the manuals (if you're lucky, the information is in there) or by scrutiny of the kernel headers. – Jonathan Leffler Mar 4 '16 at 17:27

This happened to me on windows within the Ubuntu application, while trying to run a script that wrote into /dev/null. Permissions were correct for both /dev and /dev/null.

Turned out the problem was windows newlines in the script file. Running :

dos2unix.exe c:\path\to\script.sh

Solved the issue for me.

Posting the Mac OS X answer for posterity...

sudo su \
&& rm -rf /dev/null \
&& mknod /dev/null c 3 2 \
&& chmod 666 /dev/null