Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

What is the most damage (of whatever kind) that you have ever caused with a single mistaken/mistyped/misguided command line? I deleted a production system database by mistake a while back, for example, but I was lucky (i.e. backed-up) and there was no permanent data loss, lost money, property damage etc.

Most importantly (for votes), what do you do to make sure it will not ever happen again?


locked by Michael Hampton Oct 23 '13 at 15:06

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as off topic by Mark Henderson Mar 28 '11 at 4:31

Questions on Server Fault are expected to relate to server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

Since this is a poll, it should be CW – Eddie May 6 '09 at 2:00
How should they know it's a poll progmatically? – Mikeage May 6 '09 at 8:14
If the mechanism is the same as SO's, even if you can edit a question, you can't change it to CW. Only the OP or a moderator can do that. – chaos May 6 '09 at 14:09
Good idea - post your most destructive mistake publicly on the internet for all future employers to see! :) – Sam Schutte May 13 '09 at 19:29

81 Answers 81

up vote 46 down vote accepted

In SQL server, on a production system:

update customer set password = '' <enter>

The most recent backup was like a week old.

To mitigate this, I now usually write a select statement first to make sure I've got the where clause correct, then go back and edit it to insert the set clause and change the statement to update.

Ouch. Another option would be 'BEGIN TRANSACTION'; it's nice to know you can roll back. :) – Murali Suriar May 6 '09 at 9:35
Combination of the two, select count(*) to see how many I think I'll update, and then update in transaction to do the update. If the counts match commit, if not rollback and figure out why. Of course, I don't do that for "simple" updates, and those are always the ones that screw you. :-) – WaldenL May 6 '09 at 12:47
Be careful with BEGIN TRANSACTION on a live system (or a test system being used by others too) - make sure you COMMIT or ROLLBACK soon or you may end up deadlocking other processes waiting for locks on resources your transaction holds locks on. – David Spillett Jun 7 '09 at 20:13
rm -vfr /*

Which I now do: rm -vfr ./*

Why not just "rm -vfr *"? – Ivan May 6 '09 at 0:02

cd /

rm -rf ./


the short version

what does that do? – Nathan DeWitt May 15 '09 at 2:33
It calls it's self in the background than then without waiting for that to finish, calls it's self again: a.k.a. Fork Bomb – BCS May 18 '09 at 16:50
@Masi: Not if the computer is fast enough and the script long enough. Specialy if you don't know it is going to happen. – voyager Jun 7 '09 at 22:53
Drop the #!/bin/bash, and I think this would win a code golf for shortest forkbomb in bash. – Joey Adams Apr 16 '10 at 16:42

Meant to destroy /dev/sdb, fortunately I had a good up-to-date backup

dd if=/dev/urandom of=/dev/sda

In a DOS prompt I typed the following command at my computer

C:\deltree /y *.*

Now I just select with the mouse what I want to delete and delete them.


Biggest mistake? Thinking I had set two variables when I had not. So rm -rf $VARIABLE/$VARIABLE2 became rm -rf /. FreeBSD has recently updated their rm tool so that rm -rf / is not possible anymore precisely because of this mistake!

I would like to point out, re-reading my sentence it sounds like I was the reason for changing the way rm worked, this is not the case. Apparently people were using rm in scripts and the same thing happened and they wanted to add a fail-safe. – X-Istence May 6 '09 at 7:42
i withdraw my vote then :) – Colin Pickard May 19 '09 at 20:33

Once upon a time (probably System III, but it was a long time ago), it was possible to create a file named * by using the right shell quoting. When I found one in my home directory, I had typed rm * and had my finger on the return key when something made me hesitate and think about it...

Creating such a file for other users was a common prank.

If the file is sitting there in a directory, that is a tough one to mitigate. The reflex to just type its name exactly as ls just displayed it is pretty strong.

The other (less harmful) prank was to name files with trailing white space (or only white space) which were much harder to remove...

That's what GUIs are for :) – Zifre May 6 '09 at 21:11
shell completion is a real time-saver for those trailing-space files :) – Mr. Shiny and New 安宇 May 14 '09 at 12:58
This would have been ca. 1985, and accessed via dialup or via a RS-232 cable from a clone of a VT-100 terminal. Not a terminal emulator, but an actual terminal. I don't recall csh having name completion at the time... ;-) Today, of course, GUIs and name completion make both of those less risky, and lots of OSs make it a lot harder to create such files without resorting to disk sector editing.... – RBerteig May 15 '09 at 20:18

Trying to change ownership of everything in a directory, including dot files, with:

chown -R user * .*

Guess what that does?

read mail -really fast ??? – superwiren May 29 '09 at 14:16
Been there, this taught me the .[^.]* pattern really well – Maciej Pasternacki May 31 '09 at 18:52
@chaos: The command seems to remove everything in your current directory, and even dot-files – Masi Jun 7 '09 at 20:20
@chaos: It does not remove .. and never has and never will. You are simply mistaken. Please cite a single unix implementation that does have this behavior (which I have never seen and which is documented to not be the behavior of even super-antique unixes like 7th edition unix). – chris Jun 25 '09 at 15:44
Would ./.* prevent this, or would it still propagate back up the directory tree via ./../? – tj111 Jun 25 '09 at 17:41

Working for hours and hours editing configuration file to configure an application, only to confuse the configuration file for a temporary file, and delete it. Damn auto-completion (and my own inattentiveness!)

rm -rf / some/path

instead of

rm -rf /some/path

Luckily it didn't happened to me ;-)

shutdown -h now

meant for the local workstation, but typed it while logged via ssh on production server. Since then I always have hostname in my $PS1.

Check out molly-guard ( – David Holm May 29 '09 at 20:14
I used to put the hostname in the prompt, but now I have patched the shutdown (and related - halt et al) commands to prompt me to enter the current machines name before it will execute the command. That gives me the extra step necessary to realise that I just shutdown the wrong server. Problem is, once I implemented that patch, I never did it again - but its saved a few of my colleagues tho :) – Moo Jun 11 '09 at 15:33

and now for a Win XP commandline complete screw up :

C:\Somedir> cacls.exe * /r Someuser

did something much worse than expected


I once wanted to delete a bunch of files in a directory.

del *.*

The computer then said "Are you sure? [y/N]" I thought "OF COURSE I'm sure, I wouldn't have typed the darn command in otherwise! Sheesh stupid computers grumble..."

Y <enter>


Um... WTF? Did I just erase my windows directory?....

undelete *.*

In those days of small hard disks I knew what every file in c:\windows was for and what its name was, but even after undeleting everything the system was never the same. I gained a little bit of respect for the "are you sure" prompt. Just a little.

I once did exactly the same thing. I got the system to boot and run again, but it never was quite right again. I rebuilt the system about a week later. – Jim OHalloran May 13 '09 at 23:37

My erm favorite was when I was at university. I was building an application (I don't recall what) and as I wasn't root I had built it with


So I could install it to my home directory. Unfortunately it installed into


instead. Naturally to delete it as start again i executed

rm -rf ~username

In the source directory.

I wondered why it was taking so long....


However my worst one was when I was working with a solaris workstation and after getting it all setup we wanted to wipe the configuration ready for live config. So I executed


Agreed to the warning message and instead of the machine rebooting and going back to "factory defaults" The xterm window simply said

connection closed by foreign host.

Moral of the story Don't ever leave a root shell open on another host! EVER!!

select * from <File1> join <file2>

On a production box. Note the lack of an on clause. :-) Both tables were multi-million row tables, and this was on an AS/400 in the mid 90s where once the SQL was running you couldn't kill it.


Due to some bad experience with general JBoss flakiness after a restart, I like to clear JBoss' working files before a restart. I would normally do:

# cd /var/cache/jboss
# rm -rf tmp/* work/*

In order to protect myself from typing any of the many possible disastrous mistakes, like:

  • /tmp/*
  • tmp /*
  • you get the idea

I make the last command:

# sudo -u jboss rm -rf tmp/* work/*

Since the JBoss user would find it difficult to remove any critical files that don't belong to it.

I never actually made that mistake, but I'm safe in the case that I do.


Something along the lines of this:

sudo dd if=/dev/zero of=/dev/sda

I meant sda4. I wiped the entire disk, not just the partition :-(


XCOPY is a powerful beast - merciless in it's execution and retarded by the fact that its command line args go in reverse from Window's COPY and UNIX's cp.

A couple days ago I accidentally wrote:

xcopy src \path\to\a\new\nonexistent\directory

XCOPY was kind enough to overwrite my src directory with... nothing! And it didn't bother to put the old files in the Recycle bin either.

Oh, and it turns out that XCOPY actually overwrites the same sectors on the disk instead of allocating new ones. I've tried 3 disk recovery programs, and the best one could only recover 3 of the 10 files lost. Of course those 3 files were only vshost.exe and its pals. Swell!


using joeware ad tools I had a script which was supposed to change a user account from 512 (active) to 514 (disabled user) in the useraccountcontrol attribute.

the command was:

 admod -b "userdn" useraccountcontrol::514

but I was also attempting to redirect the output by putting a 2>nul on the end, but I missed the space and the 514 became 5142 which caused AD to change user accounts to Computer accounts, this was run on a the production domain against all accounts.


On a VMS system, I had been using the ASSIGN DCL command to assign logical names, and I wanted to RECALL a previous ASSIGN command line. Now, in VMS, you only typed as many characters of a command to make it unambiguous. So I intended to type


but I accidentally typed


instead. REQ was sufficiently unambigous for the REQUEST command, which broadcasts the argument to everyone with operator privs (which was everyone in IT). So the entire department received my broadcast message which was simply "ASS".

All Software Sucks, as we all know. Why should anyone in IT think it meant something else? – Adriano Varoli Piazza Jun 20 '09 at 16:59

A free cookie to anyone who can tell me why I was an idiot for trying to remove all hidden files and directories thusly:

rm -rf .*

Does your command remove subdirectories below your current directory too? – Masi Jun 7 '09 at 20:37

Delete the payroll database... :(


Had intended to delete a text file of a similar name, PAYROLL.txt. Spent the rest of the afternoon restoring the previous backup and then running a series of audits to rebuild the payroll based on other supporting tables.

All in all, it was a pretty freaky experience (both the loss and the recovery)... :)



I was once comparing data in two folders and ran rsync with the -d option (delete files on destination that are not on the source). And then I switched around source and destination when I ran rsync. That deleted all the new files, that I wanted to backup. Now I learned running rsync with -n (dry-run).

rsync -trvd --stats --progress /destination /source

I had no backup.


When removing a config snippet I had just added into a core mpls router I was doing it by typing


then pasting in the line to remove. Unfortunately I had the wrong line in my paste buffer. I thought I had

vll id X

I was wrong and I still had the previous command in the buffer. The last thing I saw from that router before it stopped responding was

router(config)#no router mpls

Thankfully we had out of band management so I was able to get back in and restore all the mpls config from backup.

As for making sure it never happens again. First I argued with upper management that we should have automatic service deployment like we did for the switch network and I made sure "router mpls" never ever went near my paste buffer again. I always typed that line in by hand.


Easy one in - and I've done it more than once:

Del from Some_Table

without any qualification. Always do a 'select from' first now to make sure I've got the correct data.


Then the immediate feeling of terror as soon as I executed it.


Omitting the -r from a shutdown command. On a remote server. On the other side of the country. With no IT staff in the remote office.

We've all done it, it's almost like a rite of passage at this stage.

Thank god for Remote Power Control and KVMs! – Dean Perry May 14 '11 at 20:40

I think the most stupid thing I ever did was to remove the default route on out external facing firewall cluster - whilst vpn'ed to my desktop over a hundred miles away.

Fortunately it was in a period designated as planned downtime (just in case), but that did not save me the 200 mile round trip to go and reconfigure the firewall onsite. It also did not help that this took out our internet exposed production systems for the duration of my travel and subsequent fix.

We all know the definition of a nano-second. An ohno-second is even smaller, and is the time between hitting 'enter' and realising your mistake.


I was in / instead of another directory and performed the command below.

rm -Rf *

By the time I canceled the command, nearly all the /usr/ directory had been removed.


protected by Chris S Mar 17 '11 at 12:23

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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