714

Why are there so many places to put a binary in Linux? There are at least these five:

  1. /bin/
  2. /sbin/
  3. /usr/bin/
  4. /usr/local/bin/
  5. /usr/local/sbin/

And on my office box, I do not have write permissions to some of these.

What type of binary goes into which of these bins?

Improve this question
8
  • 65
    You forgot /usr/sbin/. Commented Apr 25, 2011 at 20:47
  • 45
    And ~/bin/ for personal stuff. Commented May 12, 2013 at 16:01
  • 6
    There are fewer places nowadays, since /bin was merged with /usr/bin and /sbin was merged with /usr/sbin – see The Case for the /usr Merge. Commented Feb 11, 2015 at 13:02
  • 5
    @Pacerier ~/bin is for the current user only. For example in multiuser Linux servers where you are not an admin that's the only way to "install" stuff for yourself. Commented Jul 20, 2019 at 10:30
  • 2
    @Calmarius Personal binaries go in ~/.local/bin Commented Jan 23, 2021 at 17:07

6 Answers 6

Reset to default
937

  1. /bin (and /sbin) were intended for programs that needed to be on a small / partition before the larger /usr, etc. partitions were mounted. These days, it mostly serves as a standard location for key programs like /bin/sh, although the original intent may still be relevant for e.g. installations on small embedded devices.

  2. /sbin, as distinct from /bin, is for system management programs (not normally used by ordinary users) needed before /usr is mounted.

  3. /usr/bin is for distribution-managed normal user programs.

  4. There is a /usr/sbin with the same relationship to /usr/bin as /sbin has to /bin.

  5. /usr/local/bin is for normal user programs not managed by the distribution package manager, e.g. locally compiled packages. You should not install them into /usr/bin because future distribution upgrades may modify or delete them without warning.

  6. /usr/local/sbin, as you can probably guess at this point, is to /usr/local/bin as /usr/sbin to /usr/bin.

In addition, there is also /opt which is for monolithic non-distribution packages, although before they were properly integrated various distributions put Gnome and KDE there. Generally you should reserve it for large, poorly behaved third party packages such as Oracle.

Improve this answer
8
  • 68
    I think this answer does a great job of clarifying a common set of conventions, but this post from Rob Landley is a really great read if you want insight into the nonsense... lists.busybox.net/pipermail/busybox/2010-December/074114.html Commented Dec 13, 2012 at 23:45
  • 4
    refspecs.linuxfoundation.org/fhs.shtml for the canonical current reference. The link by @kojiro is outdated and doesn't have the new spec. Commented May 3, 2016 at 18:58
  • 3
    Where do I put a bin I downloaded from the internet? From your description it sounds like it should go in /usr/local/bin or /usr/bin. Is /usr/bin something I should never manually touch, and let only the package manager play with? Commented May 3, 2016 at 19:12
  • 6
    @DidierA. put it in ~/bin and add that directory to your PATH as a user... Thanks for the note, I deleted my seriously outdated comment. Commented May 3, 2016 at 21:22
  • 6
    I found the answer to the first part of my question here: superuser.com/a/238993/425838. Precedence is based on order in the system PATH variable, and echo $PATH for me shows /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games, which means that executables in /usr/local/bin take precedence over the ones in /usr/bin which take precedence over the ones in /bin. Commented Jan 15, 2018 at 21:10
141

I recommend taking a look at the file system hierarchy man page:

man hier

which is also available online, for instance: http://linux.die.net/man/7/hier.  Relevant portions have been copied below.  Depending on your system, it may say something different.

Name

    hier - description of the file system hierarchy

Description

    A typical Linux system has, among others, the following directories:

    /bin
      This directory contains executable programs which are needed in single user mode and to bring the system up or repair it.
       
    /sbin
      Like /bin, this directory holds commands needed to boot the system, but which are usually not executed by normal users.
       
    /usr/bin
      This is the primary directory for executable programs.  Most programs executed by normal users which are not needed for booting or for repairing the system and which are not installed locally should be placed in this directory.
       
    /usr/local/bin
      Binaries for programs local to the site.
       
    /usr/local/sbin
      Locally installed programs for system administration.
       
    /usr/sbin
      This directory contains program binaries for system administration which are not essential for the boot process, for mounting /usr, or for system repair.

Improve this answer
3
  • 2
    This doesn't answer the user's question. Commented Mar 5, 2011 at 23:54
  • 33
    The man page does contain an entry for each of the bin directories, explaining what goes into them, which was one of the questions. Commented Mar 6, 2011 at 6:52
  • 4
    @BillyONeal Probably a better answer than others because it does answer the question, moreover gives a quick reference command as well. Commented May 11, 2021 at 12:36
48

The Filesystem Hierarchy Standard entry in Wikipedia helped me answer the same question when I had it, plus it has a very explanatory table.

Excerpt from that page1:

/bin        Essential command binaries that need to be available in single user mode; for all users, e.g., cat, ls, cp.
/usr/bin    Non-essential command binaries (not needed in single user mode); for all users.
/usr/local  Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin, lib, share
/usr/sbin   Non-essential system binaries, e.g., daemons for various network-services.
/sbin       Essential system binaries, e.g., fsck, init, route.

1 Retrieved on June 19, 2019; permalink.

Improve this answer
23

The sbin directories contains programs which are generally system administration only. Programs for regular users should never go in them.

A few programs are needed during startup, and end up in /bin/ or /sbin/. These must be available before file systems are mounted. Things like mount, and fsck that are required to check and mount files systems must be there.

Most packaged programs end up in /usr/bin/ and /usr/sbin/. These may be on a file system other than the root file system. In some cases they may be on a network mounted drive.

Local programs and scripts belong in /usr/local/bin/ and /usr/local/sbin/. This identifies them as clearly non-standard, and possibly only available on site.

For further explanation try running the command man hier which should provide a description of the recommended file system hierarchy for your distribution. You may also want to read about the File System Hierarchy on Wikipedia

Improve this answer
2
  • 2
    +1 A really concise explanation if top is a little too much. Commented Aug 24, 2017 at 13:09
  • "Local programs and scripts belong in /usr/local/bin/ and /usr/local/sbin/" - You mean local programs as in "not at all part of the OS, but I decided to install them and want to use them"? Commented Nov 4, 2018 at 14:46
19

In the 1970s, UNIX had all official executables in /bin and /usr/bin was a location beneath the users home directories (e.g. /usr/dmr) that was available for any user to store own binaries that might have been of interest for others as well.

The result of this open /usr/bin was a junk yard of undocumented software and so Stephen Bourne wrote a cron script that checked for new binaries every night and removed all binaries that did not have a documentation or that have been updated without updating their documentation as well.

In the late 1970s, /usr/bin was integrated into the OS base distribution and people started to use /usr/local/bin for the purpose of the previous open /usr/bin.

After a while, sysadmins used /usr/local/bin to store non-local software that was imported from the network (e.g. the USENET) and as UNIX companies did not like to repeat the same mistake as with /usr/bin again, there was a file system hierarchy conference around 1987 where all UNIX companies agreed to give up /usr/local/bin and to use /opt/<vendor>/bin instead.

Unfortunately, Linux distros did not follow this decision....

Improve this answer
4
  • 3
    While very interesting, none of this even tries to answer the question asked which was not about /opt and not about UNIX but about Linux. This is like answering "Why do cars have 4 wheels?" with "Bicycles have 2! Sadly, cars don't." which doesn't help the OP understand why cars have 4. Commented Feb 4, 2016 at 14:19
  • 2
    If you are unable to use the given explanation as an explanation to the background of Linux and the fact that Linux likes to mimic UNIX , you may be missing the needed background. Commented Feb 5, 2016 at 13:29
  • 1
    Interesting, but something I get confused on and which maybe is also only historical. Today, downloading a bin online, and a company bin isn't very different. If Joe Blow makes a program and I download it, why not put it in /opt/JowBlow/bin instead of /usr/local/bin. Is it a matter of trusted provider versus untrusted? It doesn't seem to make sense to me. Commented May 3, 2016 at 19:10
  • 1
    I wish I had known this 'exact' history a few years back. a) I wondered why AIX avoided /usr/local, uses /opt/IBM and /opt/ibm and bullfreeware uses /opt/freeware - and why I SHOULD have used a different path (not just /opt/*sbin). As to semi-relevance with Linux - better GNU tools - the default --prefix in auto-tools is /usr/local. Too bad autotools (automake, autoconf, etc. do not follow ... . But we all survive and learn where the distrub. || vendors put their programs. Commented Nov 24, 2016 at 9:00
0

UPDATE: As of 2025, the accepted answer is out-of-date. Here's a more up-to-date answer.

Breaking it down, there's two answers: historical and modern.

  1. /* vs /usr/*: today, /bin and /sbin typically link to (or from) their /usr/bin and /usr/sbin siblings, effectively making them synonyms. In the past, /bin and /sbin were separate because of files needed at startup; /bin and /sbin included files needed early in the startup process (as /usr was sometimes mounted later on).
  2. */bin vs */sbin: today, the sbin folders are usually just links to bin. Historically, the s in /sbin stood for system, and referred to core system programs, which are usually called by the system rather than the user (think drivers, not Chrome).
  3. /usr/* vs /usr/local/*: /usr/* programs are installed and owned by the distribution's package manager (e.g. apt or pacman). /usr/local/* is used for user-owned programs, e.g. locally compiled packages, that aren't owned by your package manager.
  4. /opt is mostly for packages that don't play by Unix filepath conventions.
Improve this answer
4
  • Re 2.: the /bin and /sbin directories are usually links to /usr/bin and /usr/sbin respectively- if they are links at all. In which distributions does /sbin link to /bin? I have not encountered that in RHEL or Ubuntu. Commented May 27 at 21:58
  • This answer describes a likely situation after initial installation of operating system, in some distributions of GNU/Linux. However nothing stops administrator, who likes shorter paths, to invert part of that filesystem layout and make /bin be real directory and /sbin, /usr/bin and /usr/sbin symbolic links to /bin. Commented May 27 at 23:01
  • @Arfrever yep, either can link to the other (reply edited to reflect this). Commented May 28 at 1:37
  • The merge happened on Arch and Gentoo a while back, and recently for Fedora. Debian plans to merge them but hasn't done so yet. Commented May 28 at 2:03

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.