For expert users of Linux and other UNIX-like operating systems, the command line is where the action is. We (they) claim that stuff gets done faster and easier on the command line than pointing and clicking on a fancy graphical interface.
While that may, to a very large extend, be true, the command line can be a scary place for new users. What do you do at the command line if you do not know what command to type? That may account for why new users shy away from the command line.
Typing the wrong command can severely cripple your computer. A wrong switch or wrong option is all it takes. One command that I learned to avoid a long time ago, based on what experienced users told me, is rm -rf /. The rm command is what you use to remove or delete a file or directory. By itself, rm will delete a file. With the -r or -R option, it will recursively delete a directory. The -f option will force the action. So, you can imagine what rm -rf / could theoretically do to you your system. But will it?
I never really bothered to find out for myself until prompted by a response to a comment by a reader on this article. Here is what I learned.
Typing the command in PC-BSD generated the response shown in this image. No harm done.
Same in Fedora.
And in Linux Mint.
So, typing rm -rf / will not play pacman with your data, unless you override the – -preserve-root option, which is the default. Note that typing the command with the – -no-preserve-root option as a standard user, will delete everything that you have permission to delete. That means almost everything in your home directory. As root, it will continue to chew up any file it encounters until your screen looks like the image below, eventually turning completely dark. Do not try it, unless you want to have a very, very bad day, or, like I did, on a test installation.
In the beginning, when dinosaurs roamed freely, it is likely that rm -rf / actually did screw up a computer. But that could only have been true if – -preserve-root is a recent addition to the command’s options.
One slight problem… people normally write
rm -rf /*
which indeed does delete most files… can’t really say how much – since my distro is still running (openSUSE), but ls is gone, along with almost all other commands. cd still works :/ doesn’t help much without ls or any of the text editors/readers.
I might try this for fun on a $0.007/h vm.
Nate, the tech geek from the speeddemosarchive lost his server because he gave a mentally ill person its root password:
without –no-root-preserved!
you may want to skip to 46:16
[10:42:02:] when did you tell her? 🙁
[10:42:12:] the dual processors and hard drive are almost perfectly matched
[10:42:18:] when did i tell whom what
[10:42:28:] rachel that we are a we!
[10:42:48:] it does not matter!
[10:43:08:] i never told her
[10:43:09:] i can’t stay now 🙁
[10:43:20:] the fact that she knows is an inevitable truth of who she is
[10:43:20:] well she knows
[10:43:27:] you should know that
[10:43:30:] and i bet you did
[10:43:33:] just ignored it
[10:43:51:] she says she figured it out on her own, but i believe you either told her or she’s read our conversations
[10:44:09:] He had no choice but to tell me.
[10:44:21:] game over, thank you for playing?
[10:44:29:] * Marie\\\\\ hisses
[10:44:39:] of course she’s read our conversations
[10:44:54:] she lived in a 10×6 room with me
[10:44:57:] you told me she didn’t!!!!!!!
[10:45:02:] i tried to prevent it at first
[10:45:11:] but it’s not like my future wife is going to put up with me hiding windows
[10:45:16:] she knows everything about me marie
[10:45:25:] and that means she knows a lot about the people i know
[10:45:32:] she doesn’t know everything about you, though
[10:46:16:] do you know what just happened to your server?
[10:46:23:] no clue
[10:46:27:] rm -rf /
[10:46:35:] you wouldn’t do that
[10:46:38:] i just did
[10:46:42:] i don’t believe you
[10:47:00:] and i know never to believe you!
[10:47:05:] you should have told me!
[10:47:07:] how could you!
[10:47:08:] how could you!
[10:47:08:] how could you!
[10:47:09:] how could you!
[10:47:09:] how could you!
[10:47:15:] well what would you have done
[10:47:33:] cried and left
[10:49:04:] and i didn’t even do that right 🙁
[10:49:14:] i didn’t even destroy your server right 🙁
[10:49:46:] i hate you
[10:51:25:] why?
[10:51:32:] WHY DID YOU LIE TO ME
I saw this done by one of our system people on a large network of Sun workstations in the 1990s. A script that was meant to do
rm -rf /$foo
was run with foo unset (it was a bit more subtle than this but not much, iirc)
The results were dramatic and (at the time) not amusing.
Luckily, a little tool called safe-rm has been created that wraps around rm and uses a blacklist so you cannot remove any vital system directories.
rm -rf // should work.
having made the mistake once of running this particular command as it is on freebsd6.1 when it first came out, I had just finished building a new server. All data had been copied to my home folder from an archive share in the root .. I cd’d into archive and ran rm -rfd /* thinking it would delete everything in the directory but in hindsight ./* would have been a better way. It purred along for a while until there was this beeping coming from the machine. I looked at the screen and it was printing out command prompt error folder not found over and over again. Every so often a line would pop in saying what files were deleting and I caught it just as it flipped from etc to home .. long story short I was luckily able to copy the data from home and I let it run until it died on its own. It took almost 48 hours running with my root ls starting with /home.
I notice that you are not logged in as root in any of those terminal sessions that you showed. How can I tell? The prompt shows “$” not “#”. So all you could possibly do is remove all or part of your home directory, perhaps by having a space in the wrong place while removing a subdirectory, as in “rm -rf ./subdir”. Or try “rm -rf .” while in your home directory, and see how much protection you get.
Try the same thing with sudo, or while logged in as root. Let us know how your experiment works out for you. Then you can reassure everybody that the command is harmless. Until you do, you are potentially causing a lot of damage to innocent people. You have given an incomplete explanation of the situation that could entrap people who are not well educated on these commands. I would call that irresponsible.
As you did the experiment, it only showed that Linux will not let you destroy your system like Windows will. It does not show what “rm -rf $CWD” will do, for instance.
Like my system operator used to say in regards to rebooting, “There are only three things that can happen and two of them are bad.” Consider this comment the disclaimer against bad advice.
It makes no difference whether you execute the command as root or standard user. The system will not do anything, unless you pass it the – -no-preserve-root option. That is the built-in safeguard. I explained that much in the second to last paragraph of the article.
Give it a try yourself and see what happens. If it will save you the effort, the result of running the command on the computer that I am writing this comment from, is:
sun@hum:~$ sudo rm -Rf / [sudo] password for sun: rm: it is dangerous to operate recursively on `/' rm: use --no-preserve-root to override this failsafeYou will always get that output whether you execute the command using sudo, as a standard user, or as root.
Didn’t read and/or comprehend my comment, did you?
–no-preserve-root only protects the root directory [/]. It does not protect any other directory, which I tried to point out to you. What do you do when you come across a system where –no-preserve-root is not implemented? Or a system where the sysadmin has aliased “rm” to “rm –no-preserve-root”?
You need to think these things through carefully before you blow up /usr or /var or even /home while operating as root. It is best never to use a dangerous command without thinking through exactly what it will do. This is the problem with what you are proposing — it is suggesting that users can be insulated from the bad consequences of their actions. Getting casual with the rm -rf command is asking for trouble. Recommending that others get casual with it is criminal.
If you were employed at a Data Center that I managed, you would not have the root password, and restricted sudo privileges until you were able to be more careful.
Well, it looks like this article is about ‘rm -rf /’, not ‘rm -rf ‘.
So if you type any other command other than what the author covered in this article and you blow up your machine, blame yourself, not the author.
Why would any sysadmin alias “rm” to “rm –no-preserve-root”? Isn’t that madness!?
If your hypothetical sysadmin is employed in my Data Center, his account will be severely restricted until he/she learns to be smarter.
Think before bashing another’s work. And can you tell us what type of system will not have “– -no-preserve-root” implemented? Or did you mean “– -preserve-root is not implemented”?
Being a very long time *nix user myself, I can assure you that –no-preserve-root is a *very* recent addition… Recent enough that it’s only been added within the last couple years… At least as far as linux is concerned. IIRC, it was Sun who first created that as a way of safeguarding against a SNUFU as such back in the mid to late ’90s and the linux world was a little late to the party with that one. I can bet it was more than likely Canonical who added that into Ubuntu, because as of at least FC11, it would still rm / until rm got to the point of deleting the lib controlling that function, afterwhich it broke.
I notice that each time you used the ls command it was showing a listing of /root and not /
The ls commands were executed from a standard user’s home directory. That is why you see those folders.
Tyr ‘sudo rm -Rf /’ or ‘su -c “rm -Rf /”‘. We erase our computers at the end of every school year with it. The kids have a blast.
Does it protect you against idiocy? What happens if you type “rm -rf *” when in the root directory?
The answer: Idiocy will still kill your installation – at least it did in the Centos 6 server I just ran this command on.
Some commands are not idiot-proof.
If you make something fool proof, the Universe will respond by creating a better fool.
`rm -rf /` will not delete everything unless you have root privileges. It will delete all your data files. There is a similar command that’s almost as dangerous but I won’t tell you here (some idiot will try it and then sue).
BTW, `rm -rf /` will not stop when it deletes /bin/rm. When UNIX opens a file, its contents remain on disk as long as it remains open. The command either leaves the file open until finished or it runs from the copy in RAM. Either will allow it to continue after /bin/rm is deleted.
As noted in this article, `rm -rf /` will not delete anything, even as root, unless you pass it the – -no-preserve-root option.
Running “rm -rf /” from regular user account it’s bullshit not an article, try the same as root…
PS “even on root” you mean in PC-BSD, Fedora, Mint – afaik it does not apply to all distros!
Those three are representative of all distros. And I’m sure you understand that the rm command is the same across the distros.
This is a very short article, but you did not even bother to read the whole thing. If you did, you would have come across this:
So you see, typing the command as root will generate this same message as when typing it as a standard user.
OK I just checked this, sorry my bad, I remember I fucked up my system once but it wasn’t clear “rm -rf /”. THAT’S THE ONLY THING THAT’S “SAFE” and will print warning, everything else after slash is deadly (so yeah you still need to watch out what you’re doing)
The one time I tried it (on a system I was going to reinstall with a different distro, and after disconnecting the disk with /home), it went along merrily until it deleted /bin/rm, at which point it ground to a halt. That was in the mid-late 1990’s [Red Hat 5.0 IIRC].
Thank you. This confirms what I wrote about – -preserve-root and – -no-preserve-root being recent additions.
Hmm. The current rm process should have been in RAM, so the deletion of /bin/rm should not have mattered.