How far will you get with an 'rm -rf /' command?

200

I've often wondered how far the system will actually get if you run rm -rf /. I doubt the OS would be able to erase itself (?)

Bonus Question: After the command has been executed, will rm have removed itself?

Update: I've tested this in a couple of the main unix distributions using VirtualBox and the answers describe exactly what happens. If given the correct parameters, rm will remove every physical bit of data on the disc. However, I ran into some issues when using a version of rm other than the GNU one. For example, I believe BusyBox has their own version and it doesn't let you remove as much as you potentially could.

This question was a Super User Question of the Week.
Read the July 7th, 2011 blog entry for more details or submit your own Question of the Week.

n0pe

Posted 2011-07-20T13:48:09.437

Reputation: 14 506

3I've just tried sudo rm -rf / on tinycore/microcore linux and it seems that the OS protects several directories (/sys and others) from being deleted. – n0pe – 2011-07-20T14:06:40.520

47I tried rm -f /bin/rm once. Unfortunately, it worked, and I spent the next hour getting the right version of rm back from GNU coreutils. – squircle – 2011-07-20T17:21:32.363

17Wait a sec, I will try... – Martijn Courteaux – 2011-07-20T18:16:24.127

This really depends on the operating system. Any non-Windows OS should support the command, but will inevitably handle it differently. I'd like to suggest to close this question as it is non-specific and nothing that can't be discovered for a particular OS with a virtual machine. – stimpy77 – 2011-07-20T18:31:03.630

It's funny that you asked this question. I was just answering another rm -f question on another forum and started remembering an article I read a while back. Luckily I saved it for times like this: THE classic Unix horror story Besides the fact that it's interesting to see how far it'll go... I think it's a very well written article and is a generally good read!

– akseli – 2011-07-20T13:57:50.480

@stimpy77 Even variations in how the filesystem of a given machine (even running the same OS and version of rm) will affect the result of the command. For example, if the core utilities or common commands are mounted as a memory filesystem, only loaded from disk on boot? – None – 2011-07-20T22:30:44.317

Some guy had a post long ago about (sudo) rm -Rf * on *nix vs. format c: on a Windows box (quickly changed to del \f \s \q *) – Nick T – 2011-07-21T01:40:53.683

38I do this at the apple store all the time – eggie5 – 2011-07-21T05:40:50.140

2It will not remove every bit of physical data, especially if the disk in question is an SSD! It will only unlink every file and directory. – Blacklight Shining – 2013-10-22T12:41:42.767

Answers

188

If you have rm from GNU coreutils (most probably if it's a regular Linux distro), rm -rf / will be refused by the built-in protection (according to manpage and Wikipedia, haven't tried that).

You can override this protection with --no-preserve-root. rm will then remove everything it possibly can, without stopping after having attempted to remove every single file. Of course it won't remove virtual filesystems like /proc and /sys, but that's irrelevant – it will remove everything on your disk.

After the command finishes, you disk will be wiped empty, including the OS. The kernel and current processes will continue to run from memory, but many processes will die because they will fail to access some file. The OS will fail to boot next time.

Ambroz Bizjak

Posted 2011-07-20T13:48:09.437

Reputation: 4 265

I'll note that for a brief period in early 2016 with Systemd and a UEFI motherboard/BIOS, rm -rf / could actually brick the system since efivarsfs (UEFI) is mounted read-write. See https://github.com/systemd/systemd/issues/2402 for discussion, and https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0389075ecfb6231818de9b0225d3a5a21a661171 for a kernel commit intended to resolve/prevent this.

– fencepost – 2016-03-20T00:49:05.390

67Exactly what I was looking for. Now to use this power TO TAKE OVER THE WORLD. – n0pe – 2011-07-20T15:55:16.337

34+1 especially for --no-preserve-root because that's usually not mentioned. – Matěj G. – 2011-07-20T18:29:52.433

22@MaxMackie, it's worth noting that hackers very quickly found this to be the least useful thing they could do to a user. It destroys any data that could be used for cash gains, and prevents the hacker from further exploiting the machine. Like a cat with an insect, you don't want to kill it, you just want to play with it for a while because it's fun. – zzzzBov – 2011-07-20T21:55:51.593

@Matej A quick look at the documentation for rm shows that option is well-known (or at least well-documented). – None – 2011-07-20T22:23:25.833

5To answer the OP's other question, yes rm will remove itself. It is entirely possible to modify or delete an executable even while there is an instance of it running. It will keep running, too, and will be unaffected by the change. – thomasrutter – 2011-07-21T04:44:28.700

1Yes on the built-in protection; if you attempt it it will now say "rm: it is dangerous to operate recursively on `/'". It was not so once upon a time, however... – Michael Trausch – 2011-07-21T05:57:23.533

Another way to accidentally get around the preserve-root restriction is to mount the root filesystem somewhere else (you can mount the same volumen multiple times). Did that once: you end up with a shell that doesn't have anything to call except built-ins, but is otherwise fully functional. – tdammers – 2011-07-21T08:03:00.093

@Tyler Yes, it is documented, but every time rm -rf / is mentioned, it is without --no-preserve-root (at least I have never seen it, I've found out about it from the manpage). – Matěj G. – 2011-07-21T16:57:24.900

Tried it,doesn't work – Lincity – 2011-07-23T11:37:47.163

3I would like to mention "chmod -R user:user *" at /, because it is also a recursive and costly mistake.

I did it once, and had got halfway through /home by the time I could abort. /bin /boot /etc /dev were owned.

Fortunately the server kept running while I spent the next few hours manually and resetting ownerships from a reference system.

However, noone else could use su or sudo afterwards.

Eventually discovered that /bin/su no longer had its setuid bit set. Take note for future: chowning /bin/su resets its setuid bit! – Andy Lee Robinson – 2011-07-24T20:37:47.713

I believe it won't remove a mountpoint that is in use. Is that correct? What happens to the mount if not? – XTL – 2012-03-07T12:22:50.337

Mountpoints being in use can only prevent them from being unmounted. You can still remove files from mountpoints that are in use, often including the files that are in use. However, those used files may still remain on disk if you don't shutdown properly (a hard thing to do in this case). – Ambroz Bizjak – 2012-03-07T12:29:07.837

And yeah, it won't remove the folder on the parent mount where something is mounted. But I doubt you're storing useful information as folder names :) – Ambroz Bizjak – 2012-03-07T14:42:35.720

For those who like to do stuff like this visually while listening to techno music.

Running rm- rf on Linux (video)

Bonus points if you can name the processes as they start dying.

Xeoncross

Posted 2011-07-20T13:48:09.437

Reputation: 3 274

Set up a VM and try for fun?

It'll go quite far... if you're using a gui you might have fun noticing things degrade more visibly. (icons on menus stop loading etc.)

If you let it go, the OS will pretty much be beyond recovery though you may be able to get some data back easily.

Either way, you'll be wanting to do a reinstall of the OS.

Pricey

Posted 2011-07-20T13:48:09.437

Reputation: 4 262

7I didn't even think about trying it in a VM. Going to try now! ooo this is fun. – n0pe – 2011-07-20T13:53:35.940

40Mistakenly writes the command to the host system's Terminal – slhck – 2011-07-20T13:58:07.430

1Check out the article I posted. "The Classic Unix Horror Story!" – akseli – 2011-07-20T14:00:37.273

1I'm at work right now and don't have time to go through a full install of a popular distro (ubuntu/slack/suse/fedora). If anyone else can clone a VM disk file and try it for us, it would be awesome. – n0pe – 2011-07-20T14:08:22.207

1Yes! I tried it on TinyCore running under QEMU - it was an interesting exercise... I wonder how many executable images I can get back from /proc... – new123456 – 2011-07-22T03:18:22.677

2With Amazon EC2 it should be quick to fire up one of their AMI's that already have linux installed and fire away... – David d C e Freitas – 2011-07-22T19:35:17.463

Well, trying it on http://bellard.org/jslinux/ produces:

rm: can't remove '/dev/pts': Device or resource busy
rm: can't remove '/dev': Directory not empty
rm: can't remove '/proc/swaps': Operation not permitted
rm: can't remove '/proc/kallsyms': Operation not permitted
rm: can't remove '/proc/dma': Operation not permitted

SNIP 881 entries

rm: can't remove '/proc/149/oom_adj': Permission denied
rm: can't remove '/proc/149': Operation not permitted
rm: can't remove '/proc': Device or resource busy
rm: can't remove '/tmp': Device or resource busy
rm: can't remove '/': Device or resource busy

Hello71

Posted 2011-07-20T13:48:09.437

Reputation: 7 636

1Yeah I get those errors/warnings too. Is this standard you think? – n0pe – 2011-07-20T14:28:51.573

5/proc, /sys, sometimes /dev, and any mountpoints are properties of the operating system and can't be deleted. – pjc50 – 2011-07-20T15:35:27.623

1Concurring with @pcj50, those are not literally files on the hard disk, so "deleting" them is not meaningful. – CarlF – 2011-07-20T17:11:03.320

I recall this being chewed over on alt.sysadmin.recovery back in days of yore, when there was no such thing as /proc, and /dev was just a regular directory containing entries for a bunch of unusual inodes...

... but, on some variants of Unix (my recollection is HP-UX, but that could be totally wrong), you could not remove the last directory entry for a program that was running. (Shared libraries? What are those?)

On such systems, if you started one up in maintenance mode (so nothing was running but your shell, not even init, and no secondary file systems were mounted) and did exec /bin/rm -rf /, you would be left with a completely empty root file system except that /bin and /bin/rm would survive.

The denizens of the scary devil monastery considered this to be fitting and proper.

zwol

Posted 2011-07-20T13:48:09.437

Reputation: 1 130

rm -rf / shouldn't be allowed on recent implementations as it has been suggested it violates the POSIX standard:

"rm -rf /" protection on Oracle blog

Anyway, in the end, we got the spec modified, and Solaris 10 has (since build 36) a version of /usr/bin/rm (/bin is a sym-link to /usr/bin on Solaris) and /usr/xpg4/bin/rm which behaves thus:
[28] /bin/rm -rf /
rm of / is not allowed
[29] 

jlliagre

Posted 2011-07-20T13:48:09.437

Reputation: 12 469

2"pointing out that if one attempts to remove "/" recursively, one will ultimately attempt to remove ".." and ".", and that all we are doing is allowing rm to pre-determine this heuristically. Amazingly, they bought that! " - er, wouldn't that disallow removing any directory? The actual spec only disallows .. and . in the actual command-line arguments, it doesn't say anything about what you "ultimately attempt to remove" – Random832 – 2011-07-20T16:22:32.277

1Why would it disallow removing any directory ? The root directory is the only concerned here and removing it obviously imply removing "." and "..", whatever the current directory is. Common sense isn't forbidden in standard interpretation. – jlliagre – 2011-07-20T20:57:59.297

1That line of argumentation is pure genius. – Nate C-K – 2011-07-20T22:09:39.307

The standard specifies that rm is not allowed to continue if an argument has the string "." or ".." as the basename component. You cannot remove /foo/.. even if you're not in /foo. It does not specify that you're not allowed to remove the current directory (e.g. rm -r \pwd``) or the parent of the current directory. – Random832 – 2011-07-20T22:30:12.273

2Indeed, I misunderstood the statement and you are correct. Hopefully, the standard guys accepted the smarter behavior as being standard compliant. Removing large parts if not all of the file system would quickly make the OS non standard compliant anyway. – jlliagre – 2011-07-20T22:44:01.867

One point I didn't see made by anyone else: files that are currently open (e.g. rm itself), even if deleted, won't actually disappear fom the drive until closed.

CarlF

Posted 2011-07-20T13:48:09.437

Reputation: 8 576

That's right, because they're loaded in memory right? – n0pe – 2011-07-20T17:15:08.310

I'm not sure if that is safe to assume; the kernel could very well just load the removed file into memory and remove it on the disk immediately, and keep this in-memory copy until the file is open (e.g. until rm is running). – Ambroz Bizjak – 2011-07-20T17:25:35.857

I'm not speculating. If a program is running, deleting it does not remove it on my Linux boxes, at least. (Mind you I haven't tested this in, oh, a couple of years.) – CarlF – 2011-07-20T19:25:09.433

4rm will remove itself from the fs - the program is completely loaded in memory, not the file – warren – 2011-07-20T19:25:14.730

@warren, absolutely right, but at least in my experience the file on disk is not removed (in the sense of not appearing in a listing) until it is closed. – CarlF – 2011-07-20T19:29:13.487

4@MaxMackie: not because they're loaded in memory, but because an open file reference have the same power as a hard-link (i.e. if a file has at least one hard link, it won't be deleted from the disk). – Lie Ryan – 2011-07-20T19:49:33.380

@CarlF - last time I tried doing an rm -rf /, it deleted everything except the boot-generated mounts – warren – 2011-07-20T20:43:33.210

@Lie Ryan: Yes, it's not removed from the disk, but the pointer to the file is removed from the directory where it used to be. This means you can recover a recently-deleted file from e.g. ext3, but it is messy. – Piskvor left the building – 2011-07-21T07:45:52.623

@Piskvor but you have to recover the files before the program closes :) – João Portela – 2011-07-22T14:07:28.880

@Piskvor: This doesn't apply to only ext*s; simply only *nix systems where /proc is actually mounted. – Hello71 – 2011-07-25T14:07:55.230

@Hello71: I did mention ext3 as an example, but good point with /proc – Piskvor left the building – 2011-07-25T14:18:49.440

For having tried it once (on a server that what pissing me off), logged as root, in terminal, you'll lose almost everything. The only thing that'll not be erased will be only the process that was essential for the OS.

Anarko_Bizounours

Posted 2011-07-20T13:48:09.437

Reputation: 280

1chmod -fR 777 / is harmful because it turns off the setuid and setgid bits. – G-Man Says 'Reinstate Monica' – 2015-06-17T20:47:13.920

12"[not erased] only the process that was essential for the OS" - oh, don't worry. Unlike Windows, Linux will happily erase anything, even if the file is OS-critical and in use. /boot, /sbin, /etc, /bin, /vmlinuz? Bam, gone. Good luck booting without those - in fact, good luck doing anything at all once the delete is finished. – Piskvor left the building – 2011-07-20T16:26:12.563

If I recall there was some file that wasn't deleted, and I let my linux run for more than 4 hours. But still, it's good to know what happen, like doing a chmod 777 /* -fR ;) – Anarko_Bizounours – 2011-07-21T07:25:01.167

3"chmod 777 /* -fR" - That should just make the system very insecure, though very user-friendly. – Bart van Heukelom – 2011-07-26T18:41:09.893

did it, it's very insecure. You can't do a thing, some process need to have specific right, and the chmod 777 will change every right, you'll never be able to load a session, and some process to. – Anarko_Bizounours – 2011-07-27T06:35:02.340

1@BartvanHeukelom, some tools will perform a quick self-test, or be tested by the system for proper ownership and permissions and refuse to act if malconfigured. – killermist – 2012-07-27T12:40:33.537

How far you can get, it's basically depend on the specific Unix/Linux distributions.

But to answer your base question, yes - rm command would be removed with it as well as any other standard command in /bin and other folders.

Here is the simple test which I've performed in Linux Ubuntu 15.04 using VM.

Initialize virtual machine via vagrant:

vagrant init ubuntu/vivid64 && vagrant up --provider virtualbox && vagrant ssh

Then when you're trying to remove all the files in the standard way, it doesn't let you:

vagrant@vagrant-ubuntu-vivid-64:~$ sudo rm -fr /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

So lets try --no-preserve-root. Always double check you're logged in virtual machine (so you're having vagrant@vagrant-ubuntu-vivid-64:~$), then run (don't try that at home):

vagrant@vagrant-ubuntu-vivid-64:~$ sudo rm -vfr --no-preserve-root /
removed directory: '/lost+found'
removed directory: '/opt'
removed '/bin/nc'
removed '/bin/less'
removed '/bin/wdctl'
removed '/bin/nano'
...
removed '/bin/rmdir'
removed '/bin/sh'
removed '/bin/rm'
...
removed directory: '/bin'
removed directory: '/usr/games'
removed '/usr/bin/byobu-launcher-install'
removed '/usr/bin/ipcmk'
removed '/usr/bin/sum'
removed directory: '/usr/bin'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9.2'
removed '/usr/lib/gcc/x86_64-linux-gnu/5.0.1'
removed directory: '/usr/lib/gcc/x86_64-linux-gnu/5'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libquadmath.so'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libgomp.so'
...
removed directory: '/run/initramfs'
removed directory: '/media'
rm: cannot remove '/proc/fb': Operation not permitted
rm: cannot remove '/proc/fs/ext4/sda1/options': Operation not permitted
...
removed '/vmlinuz'
removed '/boot/config-3.19.0-23-generic'
removed '/boot/grub/grubenv'
...
removed directory: '/boot'
removed '/lib64/ld-linux-x86-64.so.2'
rm: cannot remove '/dev/hugepages': Device or resource busy
rm: cannot remove '/dev/mqueue': Device or resource busy
rm: cannot remove '/dev/shm': Device or resource busy
removed '/dev/vcsa7'
...
removed '/dev/mem'
removed '/dev/rfkill'
removed '/dev/vga_arbiter'
...
rm: cannot remove '/sys/fs/ecryptfs/version': Operation not permitted
removed directory: '/etc'
removed directory: '/mnt'
removed '/vagrant/.vagrant/machines/default/virtualbox/action_provision'
removed '/vagrant/.vagrant/machines/default/virtualbox/action_set_name'
removed '/vagrant/.vagrant/machines/default/virtualbox/creator_uid'
removed '/vagrant/.vagrant/machines/default/virtualbox/id'
removed '/vagrant/.vagrant/machines/default/virtualbox/index_uuid'
removed '/vagrant/.vagrant/machines/default/virtualbox/private_key'
removed '/vagrant/.vagrant/machines/default/virtualbox/synced_folders'
removed directory: '/vagrant/.vagrant/machines/default/virtualbox'
removed directory: '/vagrant/.vagrant/machines/default'
removed directory: '/vagrant/.vagrant/machines'
removed directory: '/vagrant/.vagrant'
removed '/vagrant/Vagrantfile'
rm: cannot remove '/vagrant': Device or resource busy

After that it gets back to the shell prompt like nothing just happened, but you can't execute any commands anymore apart of few built in and kill, so you can finish your job and kill your session:)

For example:

$ rm
rm: command not found
$ kill
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
$ which kill
-bash: /usr/bin/which: No such file or directory
$ kill -9 $$
Connection to 127.0.0.1 closed.

So it pretty removed everything, including rm, ls and all other commands, but still you're logged-in. There are some special folders which weren't removed such as some devices from /dev, /proc or /sys which are aren't regular directories/files, but it's pseudo-filesystem providing interfaces to process and kernel data.

If you don't have Vagrant or Linux, you can play with some JavaScript Linux x86 emulators.

If you're interested in possibilities of recovering from such disaster, check:

Monday morning mistake: sudo rm -rf --no-preserve-root /

kenorb

Posted 2011-07-20T13:48:09.437

Reputation: 16 795