Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I read the Wikipedia article on /dev/null and was playing around by moving files to /dev/null.

For this I created a test_file and put some contents in it:

$ touch test_file
$ echo "This is written by Aditya" > test_file
$ cat test_file
This is written by Aditya

Thereafter I tried to move the file to /dev/null:

$ mv test_file /dev/null
mv: inter-device move failed: ‘test_file’ to ‘/dev/null’; unable to remove target: Permission denied

Since, this gave me a Permission denied Error; I went ahead and used sudo as I normally do whenever I encounter a Permission denied error.

$ sudo mv test_file /dev/null

The command succeeded and test_file is no longer present in the directory.

However, the Wikipedia article says that it is not possible to recover anything moved to /dev/null and it gives an EOF to any process that tries to read from it. But, I can read from /dev/null:

$ cat /dev/null
This is written by Aditya

What did I do wrong and how do I fix /dev/null back to normal? And why did I encounter Permission denied error in the first place?

share|improve this question
Fix it now (read my comments on @Benoit answer). You can end with "This is written by Aditya" in the middle of ANY important file in your system... – Rmano Mar 18 '14 at 14:09
If you want to experiment with /dev/null and /dev/zero, you can create your own copies with sudo mknod in your directory --- it's safer and will not interfere with your system. – Rmano Mar 18 '14 at 14:15
"sudo as I normally do whenever I encounter a Permission denied error." - that's not a great tactic. Understand why the permission was denied, before blindly invoking sudo. – artbristol Mar 18 '14 at 14:15
@artbristol: That's a great advice to understand the why before committing to do anything. As a novice Linux user myself, could you guide me how I can proceed to understand the reasons for denial of permission whenever I encounter such situations? – Aditya Mar 18 '14 at 17:39
@artbristol +1 -- if you don't understand why you don't have permission then it's probably because you shouldn't do that. – Bakuriu Mar 18 '14 at 19:09
up vote 133 down vote accepted

/dev/null is a file. A special file. A device file like /dev/sda or /dev/tty that talks to a piece of hardware on your system.

The only difference with /dev/null is that no hardware is linked to it. Any data you send to it is silently discarded. Like the following command:

$ echo "Hello World" > /dev/null

which won't print anything on your terminal because you send the output of echo to null, to the void, a black hole thus.

But when you did mv test_file /dev/null you've replaced the special file /dev/null by a normal text file, holding a copy of the content of your test_file. In other words, you've lost your /dev/null.

Now, what you have to do is (to reconstruct it):

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

chmod is required to fix the permissions as noted by hope in his answer.

You should reconstruct it because a lot of script send by defaut output to /dev/null. If /dev/null is no more a black hole but a regular text file, it may grow, grow and fill your file-system up. And I'm sure you want to avoid this.

And much more dangerous, a lot of scripts assume that reading from /dev/null will read nothing; breaking this assumption can lead to random garbage written in files all around your system... practically impossible to fix up.

And remember that Linux is multi-tasking: while you are playing with /dev/null, a lot of processes are running and can wreak havoc even during a few seconds "window of opportunity".

If you want to play with /dev/null you can create a copy and experiment with it:

sudo mknod -m 0666 /tmp/null c 1 3 

Will create a /tmp/null file that works in the exactly same way of /dev/null but that you can manipulate and test without any risk for your system.

share|improve this answer
/dev/null doesn't 'grow'. Anything you send to /dev/null replaces whatever was there at first. Try running echo "Hello World" > /dev/null, check the contents of /dev/null then run echo "" > /dev/null and check again. – Parto Mar 18 '14 at 12:39
@Avatar Parto: in the case submited here, where /dev/null as been accidently replaced by a regular text file, it will grow. Of course I know that under normal circumstances /dev/null doesn't grow. But with this question, we are no more in normal circumstances. – Benoit Mar 18 '14 at 12:42
echo "something" > /dev/null will always overwrite. But if for some reason the command is echo "something" >> /dev/null it will grow. – Benoit Mar 18 '14 at 12:45
The main problem when replacing /dev/null with a regular file is that your are supposed to be able to do command < /dev/null and have 0 bytes in and an immediate End-Of-File --- useful for saying "no input" to commands that expect input. Having real, random data returned will wreck havoc all around. – Rmano Mar 18 '14 at 14:04
@Benoit: While of course >> will make it grow, there are surely lots of occasions where some script/tool will truncate by just redirecting. Anyways it doesn't matter if it grows or not, there are more important reasons; they are listed in the answer and are much more of a reason to restore the device node. – PlasmaHH Mar 18 '14 at 20:19

@Benoit is nearly correct in his answer. You will also need to fix permissions.

$ sudo rm /dev/null
$ sudo mknod /dev/null c 1 3
$ ls -l /dev/null
crw-r--r-- 1 root root 1, 3 Mar 18 08:38 /dev/null
$ sudo chmod 666 /dev/null
$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Mar 18 08:38 /dev/null

This restores the permissions. Otherwise, as a non-root user you wouldn't be able to echo foo > /dev/null.

share|improve this answer
that 666 mode is also a good reminder of the care you need to take with /dev/null ^^ – Olivier Dulac Mar 19 '14 at 17:22

There is a big difference between overwriting a file and writing to a file.

When you write something to /dev/null, e.g.,

$ echo Hello > /dev/null gets silently discarded. For this you need write permissions to /dev/null, which everyone has:

$ ls -l /dev/null 
crw-rw-rw- 1 root root 1, 3 Mar 18 13:17 /dev/null

When you overwrite /dev/null, as you did with the mv command, you replace the special file /dev/null with whatever you moved there. Don't do this! The reason you needed root privileges to do that is because to overwrite a file, you need write permissions to the directory that contains the file, in this case /dev:

$ ls -ld /dev
drwxr-xr-x 16 root root 4640 Mar 18 13:17 /dev

To restore /dev/null, issue the commands

$ sudo rm /dev/null
$ sudo mknod -m 0666 /dev/null c 1 3

(Also see U&L StackExchange: How to create /dev/null)

share|improve this answer

When you run the command

$ sudo mv test_file /dev/null

you have replaced the special file /dev/null with your text file. Subsequent attempts to read from /dev/null return the contents of your text file, and programs that attempt to use /dev/null in the normal way will probably break.

Replacing or deleting device files in /dev/ requires superuser privileges, which is why your non-sudo attempt failed with an error.

See Benoit's answer for information on how to restore /dev/null manually, but since most (if not all) of the content of /dev/ is managed dynamically by udev, I suspect a simple reboot will probably fix it too.

share|improve this answer
sudo mknod /dev/null c 1 3 will reconstruct /dev/null – Benoit Mar 18 '14 at 12:35
mknod: ‘/dev/null’: File exists – Avinash Raj Mar 18 '14 at 13:01

To answer your question of what you should have done, to remove a file, you do:

rm test_file

As others have stated, /dev/null is a destination for the output of programs.

share|improve this answer
I don't know why I was given a -1. I realize it's a simple answer, maybe too simple for most, but the poster's goal was to make a file vanish, and no one actually addressed that. – mlv Mar 18 '14 at 18:10
I didn't downvote, but the question is not about removing file... I know we use rm to remove files/directories... I just read about /dev/null and in order to understand more about it, I tried to move files to /dev/null and see the effect.. This question is about understanding what did I do wrong by moving files to /dev/null as a result of which I can read from it now... The question is not about how to remove files from system... I hope it is clear... But your answer is still welcome and good enough to be kept as an answer... :-) – Aditya Mar 18 '14 at 18:18
To be fair, asking "What did I do wrong" kind of calls for an explanation of what should have been done instead. It probably is trivial for most users but none of the other answers even mentioned it. – Kapep Mar 19 '14 at 3:48
@mlv: The op tried to break something on his system (inadvertently) but was preventing from doing so, then used sudo to do it anyway. While your answer technically responds to the "how do i remove a file" part, there should be a huge warning to not use sudo unless one understands what is done and why. I think the root cause has nothing to do with deleting files, but with responsibility. – basic6 Jul 9 '15 at 11:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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