We all know the destructive power of the following command executed as root:

rm -rf /

Related questions:

I fail to see when this particular combination of parameters would be useful, since it destroys the whole system and there are more efficient ways to do that. The rm command could check for these specific parameters, and implement some kind of safeguard - ask for confirmation at the very least, despite the -f parameter.

Why is there no such safeguard in the rm command?

I'm well aware that you must be extra careful when you execute commands as root. With great power (...). However shouldn't this specific case be an exception to that rule?

  • 8
    I imagine that there is a philosophical bias against it. After all, once you get into the protecting users from themselves business, where should you stop? Sep 15, 2011 at 12:43
  • 2
    Like many, i've done this mistake before now (actually, rm -r $variable/ when $variable turned out to be empty). I put the blame on myself for being stupid, not the o/s for not holding my hand, and i wouldn't want it any other way.
    – Sirex
    Sep 15, 2011 at 13:37
  • What if rm -rf / is performed after chroot?
    – mouviciel
    Sep 15, 2011 at 14:10
  • @Sirex I know that situation rather well. set -u is your friend. If you set variable= though, nothing can save you except defensive programming.
    – Daniel Beck
    Sep 15, 2011 at 14:50
  • The command can brick UEFI devices
    – Suici Doga
    Mar 20, 2016 at 10:53

2 Answers 2


It depends on the distribution. The older Linux I'm on right now allows it (I think, didn't test it though :-) ) and states in man rm:

   --no-preserve-root do not treat '/' specially (the default)

          fail to operate recursively on '/'

On many recent distributions, you need to explicitly add --no-preserve-root to disable the safeguard. Otherwise it will fail to execute.

Regarding Ubuntu, see this issue where this behavior is discussed.

The history of this protection according to Wikipedia:

Sun Microsystems introduced rm -rf / protection in Solaris 10, first released in 2005. Upon executing the command, the system now reports that the removal of / is not allowed. Shortly after, the same functionality was introduced into FreeBSD version of rm utility. GNU rm refuses to execute rm -rf / if the --preserve-root option is given, which has been the default since version 6.4 of GNU Core Utilities was released in 2006.

  • +1: I didn't know that (and didn't try in a VM). So I guess my question is a bit late... Sep 15, 2011 at 10:46
  • Could you specify the Linux distribution and version you used? Sep 15, 2011 at 10:47
  • @Laurent I edited my answer in the mean time. I'm on RHEL5.6 right now and it allows the command by default.
    – Daniel Beck
    Sep 15, 2011 at 10:49
  • And thanks to @slhck we now know why my RHEL doesn't like it, it's software from early 2006 AFAICT.
    – Daniel Beck
    Sep 15, 2011 at 10:50
  • @slhck I don't think so.
    – Daniel Beck
    Sep 15, 2011 at 10:51

Why is there no such safeguard in the rm command?

There are already three safeguards:

  • The -r switch, without which a directory can't be removed.
  • The -i switch, which verifies that you actually want to delete what you've asked to delete. Aliasing rm to rm -i turns that safeguard on unless you add the -f switch to turn it off.
  • File ownership, which prevents all users but root from deleting the root directory.

The Unix toolset is like a chainsaw: it was designed to do very powerful things and be wielded by people who understand what they're doing. Those who tread carelessly are likely to end up injuring themselves. This isn't to say that the experienced don't make mistakes, and obviously Sun and others feel that users with root need to be protected from themselves.

However shouldn't this specific case be an exception to that rule?

People have been asking why we can't put a blade guard over the rm chainsaw since at least the 1980s. (Probably longer, but my history with Unix doesn't go back any further than that.) You have to ask yourself more questions:

  • Since we're adding exceptions, what else should be considered sacred? Should we prevent recursive deletion of anything in the root directory to avoid equally-devastating mistakes like rm -rf /*? What about the user's home directory? What about /lib or /bin? Would we have to have a special version of rm to prevent these mistakes on systems with a nontraditional file system layout?

  • Where do we put the enforcement of these prohibitions? Just in rm or do we give the kernel that job? Since rm doesn't actually delete anything (it makes lots of calls to unlink(2) and rmdir(2) based on the arguments), there would be no way for the kernel to detect that rm was really gunning for / until the moment actually came to delete it. Since the only call to rmdir(2) that would ever succeed is when the target directory is empty, reaching that point with / would mean the system's already done for.


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