Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

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

Edit - please see this duplicate question.

I just chowned -R my /usr folder, which totally corrupted my computer (not sure how, but I lost sudo power eventually). This seems like a horrible newb mistake.

Are there other ones I should avoid?

share|improve this question

closed as not a real question by Michael Mrozek Apr 11 '11 at 15:50

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

I suspect this will lead to some disagreement, but I'm going to close this; "please make a list of everything not to do on a *nix machine" is massively broad and not very helpful -- people aren't going to consult this list before running commands – Michael Mrozek Apr 11 '11 at 15:50
I don't think so. Many people have a general fear of doing something wrong in this unspecific manner, since Unix/Linux is often 'advertised' as expert system. Let's show them a way how to deal rationally with the doubt. – user unknown Apr 11 '11 at 16:59
Avoid the mistakes mentioned in What are your favorite painful Unix moments. – Gilles Apr 11 '11 at 19:52
@Gilles Ah, there it is; I thought we had a similar post from the early days, but I couldn't find it – Michael Mrozek Apr 12 '11 at 3:11

Fast people don't hurry

Don't use not so well known programs or commands untested in a hurry. If you don't have enough time, think about how many time you need if it is going wrong.

Use a lab for experiments, often

You should read the man page for new commands, and test things, which are unclear, in a testing directory, where you have normal files, hidden files, links, symbolic links, subdirs and everything. Where it is no drama if something get lost. You could even use a chroot environment or a VM-Installation to have a sandbox.

Backup often

And you should have daily backups. If you're not using it seriously (important posts, photos, valuable work) you don't need daily backups, but if they are very valuable, you should do hourly backups.

A backup of your lab would be fine, and needn't be so much up to date.

share|improve this answer
These are very general tips, I was aiming for something a bit more concrete. – ripper234 Apr 11 '11 at 18:36
There are hundrets of things, which could be wrong and 100*100 if you combine two of them. But for many of them, one of the above might be a solution or stop your losses. – user unknown Apr 11 '11 at 18:39

Login as root, you should always use sudo if you want to run something as root. And if you for some reason login as root you should be really careful.

share|improve this answer
I think you meant to say "do not login as root". :-) – Faheem Mitha Apr 11 '11 at 15:16
the question is "What horrible mistakes should I avoid as a newb?" the mistake is "login as root". – hiena Apr 11 '11 at 15:35

If you're working with disk partitions, make sure the device is what you think it is. The other day I accidentally formatted my external hard drive thinking it was my USB flash drive. My external drive is almost always /dev/sdc, but that day I booted up with my flash drive plugged in, so for whatever reason my external drive was /dev/sdd, which is what I formatted instead of my USB flash drive.

There are probably a lot of ways to check what a device really is, but one way is to just mount the partition and check the contents before you make an attempt to destroy it.

Another way is to run this:

ls -l /dev/disk/by-id/

This will show the labels on your devices and tell you which file they are in /dev/ they are, i.e. ata-Maxtor_6Y080L0_Y2VW7QWE -> ../../sda

share|improve this answer
I usually go with sudo sfdisk -l, which works as long as you can identify the disk based on the partition layout. – intuited Apr 11 '11 at 18:22

rm -rf ~ and especially rm -rf /.

The rm command is the delete or remove command. The -r flag tells rm to delete recursively and the -f flag tells it to never prompt.

Also there are a few typos you should watch out. This one has already bitten me. I wanted to delete all *.swp files so I ran rm * .swp. Can you spot what's wrong with it?

share|improve this answer
I make a habit of adding the flags after the directory (e.g. rm /some/dir -rf) so that rm -rf /some/obsolete/directory doesn't get turned into rm -rf / by an accidental press of the Enter key. Not sure how universally this can be done. – intuited Apr 11 '11 at 18:17

FORKBOMB. That's one of the worst things you can do to your machine. Here's the link that explains it.

Also, in my opinion, never do anything as root unless absolutely necessary.


share|improve this answer
Well, considering that the worst-case scenario is a cold shutdown without much chance of file corruption, I wouldn't call it one of the worst things you can do, but it's a PITA, yeah. I don't consider the suggestion worth a downvote, in any case. – intuited Apr 11 '11 at 18:21
Considering the thing the questioner did, I thought putting up forkbomb in the list would be good. Dunno why someone would downvote it. :) – Dharmit Apr 11 '11 at 18:49
quote from your link: Properly configured Linux / UNIX box should not go down when fork() bomb sets off. It's a good load test, but not fatal. – Rory Alsop Apr 11 '11 at 19:16

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