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?


4 Answers 4


/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 -m 0666 /dev/null c 1 3

You should reconstruct it because a lot of scripts by default send 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.


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

...it 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)


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.


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.

  • 2
    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, 2014 at 18:18
  • 7
    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.
    – kapex
    Mar 19, 2014 at 3:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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