-bash: /dev/null: Permission denied

Question

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?

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

score 85 · Accepted Answer · edited Mar 29 '21 at 08:06

85

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.

1 and 3 here are the device major and minor number on Linux-based OSes (the 3rd device handled by the mem driver, see /proc/devices, cat /sys/devices/virtual/mem/null/dev, readlink /sys/dev/char/1:3). It varies with the OS. For instance, it's 2, 2 on OpenBSD and AIX, it may also not be always the same on a given OS. Some OSes may supply a makedev / MAKEDEV command to help recreate them.

edited Mar 29 '21 at 08:06

Stéphane Chazelas

522,931
91
1,010
1,501

answered Jul 25 '14 at 21:31

Mark Plotnick

24,913
2
59
81

19

If by "someone" you mean "me", then yes :) – Kevin Burke Jan 21 '15 at 21:50
Even i ran int the same issue on server. ubuntu 14.04 LTS. But I didn't change permissions. Is there any possiblity where I can track which process changed the permissions? – Mani Apr 05 '18 at 05:19
@Mani Linux by default doesn't log such small changes, but you can turn on auditing to see them from now on. [How to detect on Linux chmod of a file](https://stackoverflow.com/questions/39391286/how-to-detect-on-linux-chmod-of-a-file) – Mark Plotnick Apr 05 '18 at 16:14
1

The solution fixes the problem but the issue reoccurs. Why? – code Oct 06 '18 at 03:40
@AbhishekSoni You might try auditing, as described in [Display a file's history (list of users that have modified a file)](https://unix.stackexchange.com/questions/42234/display-a-files-history-list-of-users-that-have-modified-a-file) – Mark Plotnick Oct 11 '18 at 17:47

jlliagre · Answer 2 · 2020-03-09T11:31:53.183

21

This should fix the issue (as root):

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

What these commands are doing:

rmis removing the bogus file that has been created because the expected one was missing;
mknod is creating a character device named /dev/null with the appropriate major and minor numbers for a Linux kernel;
chmod is setting the permissions for all users to be able to read and write to /dev/null.

edited Mar 09 '20 at 11:31

answered Jul 25 '14 at 21:27

jlliagre

60,319
10
115
157

2

This one also works on Mac/BSD – redolent Feb 11 '15 at 23:06
this answer works but can yu explain those cmds? @jlliagre – AATHITH RAJENDRAN Mar 09 '20 at 09:03
@AATHITHRAJENDRAN Explanations added. – jlliagre Mar 09 '20 at 11:32

score 6 · Answer 3 · edited Mar 29 '21 at 08:19

6

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.

To re-create all standard devices on OpenBSD (null included), you should use (as root):

cd /dev
./MAKEDEV std

edited Mar 29 '21 at 08:19

Kusalananda

320,670
36
633
936

answered Mar 15 '15 at 16:53

meschi

61
1
3

Didn't the OP use CentOS rather than OpenBSD? – ott-- Mar 15 '15 at 18:23
6

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
1

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 04 '16 at 17:27

score 2 · Answer 4 · answered Mar 09 '19 at 06:49

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.

score 1 · Answer 5 · edited Mar 29 '21 at 07:54

1

Posting the Mac OS X answer for posterity...

sudo sh -c '
  rm -rf /dev/null &&
    mknod /dev/null c 3 2 &&
    chmod 666 /dev/null'

edited Mar 29 '21 at 07:54

Stéphane Chazelas

522,931
91
1,010
1,501

answered Aug 23 '18 at 15:23

Julian

111
3

1

@Kusalananda, I've corrected that. I can't comment on whether 3, 2 are the correct major/minor on macos or not. – Stéphane Chazelas Mar 29 '21 at 08:07
@StéphaneChazelas `3 2` should be correct. – Kusalananda Mar 29 '21 at 08:16

score 1 · Answer 6 · answered Jul 10 '20 at 14:19

1

For IBM AIX Server i did the same and it's working

# rm /dev/null;mknod /dev/null c 2 2;chown root:system /dev/null;chmod 0666 /dev/null

# ls -l /dev/null
crw-rw-rw-    1 root     system        2,  2 Jul 10 22:18 /dev/null

answered Jul 10 '20 at 14:19

Namasivayam Chinnapillai

163
1
4

Welcome to the site, and thank your for your contribution. Please note that your solution looks very much like the [accepted answer](https://unix.stackexchange.com/a/146639/377345). You may want to edit it to make the difference more clear. – AdminBee Jul 10 '20 at 15:00
Yes, for AIX it is major=2, minor=2 not the same as it is in Linux. – Lorinczy Zsigmond Jul 10 '20 at 18:37

-bash: /dev/null: Permission denied

6 Answers6

Linked