According to the Filesystem Hierarchy Standard, /opt is for "the installation of add-on application software packages". /usr/local is "for use by the system administrator when installing software locally". These use cases seem pretty similar. Software not included with distributions usually is configured by default to install in either /usr/local or /opt with no particular rhyme or reason as to which they chose.

Is there some difference I'm missing, or do both do the same thing, but exist for historical reasons?

  • 2
    My understanding is that /usr/local is a local version of /usr file system, whereas /opt is place holder for misc stuff. – yasouser Apr 19 '11 at 13:11
  • 4
    Similar question in Ask Ubuntu, superuser – kenchew Oct 7 '16 at 12:40
up vote 306 down vote accepted

While both are designed to contain files not belonging to the operating system, /opt and /usr/local are not intended to contain the same set of files.

/usr/local is a place to install files built by the administrator, typically by using the make command (e.g., ./configure; make; make install). The idea is to avoid clashes with files that are part of the operating system, which would either be overwritten or overwrite the local ones otherwise (e.g., /usr/bin/foo is part of the OS while /usr/local/bin/foo is a local alternative).

All files under /usr are shareable between OS instances, although this is rarely done with Linux. This is a part where the FHS is slightly self-contradictory, as /usr is defined to be read-only, but /usr/local/bin needs to be read-write for local installation of software to succeed. The SVR4 file system standard, which was the FHS' main source of inspiration, is recommending to avoid /usr/local and use /opt/local instead to overcome this issue.

/usr/local is a legacy from the original BSD. At that time, the source code of /usr/bin OS commands were in /usr/src/bin and /usr/src/usr.bin, while the source of locally developed commands was in /usr/local/src, and their binaries in /usr/local/bin. There was no notion of packaging (outside tarballs).

On the other hand, /opt is a directory for installing unbundled packages (i.e. packages not part of the Operating System distribution, but provided by an independent source), each one in its own subdirectory. They are already built whole packages provided by an independent third party software distributor. Unlike /usr/local stuff, these packages follow the directory conventions (or at least they should). For example, someapp would be installed in /opt/someapp, with one of its command being /opt/someapp/bin/foo, its configuration file would be in /etc/opt/someapp/foo.conf, and its log files in /var/opt/someapp/logs/foo.access.

  • 40
    /usr/local, for self, inhouse, compiled and maintained software. /opt is for non-self, external, prepackaged binary/application bundle installation area. Hmmm...we do not have C:\program files for everything ;-) – Nikhil Mulley Feb 2 '12 at 12:49
  • 2
    "On the other hand, /opt is a directory where to install unbundled packages" What does 'unbundled' packages mean here? – Kevin Wheeler Aug 16 '15 at 1:54
  • 1
    @KevinWheeler That is explained in the next sentence. Unbundled means packages not part of the Operating System distribution but provided by an independent source. – jlliagre Aug 16 '15 at 1:59
  • 1
    @jlliagre the centos docs* state "For instance, if the /usr/ directory is mounted as a read-only NFS share from a remote host, it is still possible to install a package or program under the /usr/local/ directory" I don't know who is right, but this seems to be in contradiction to your claim about an area where FHS is weak. (*source centos.org/docs/5/html/5.1/Deployment_Guide/…) – Kevin Wheeler Dec 6 '15 at 11:44
  • 1
    @KevinWheeler That's precisely the weakness I'm referring to. Installing a package or a program in a remote, read-only directory is just impossible. The workaround would be to mount a local file system on /usr/local but this looks more like a makeshift job than a something properly designed. – jlliagre Dec 6 '15 at 13:05

The basic difference is that /usr/local is for software not managed by the system packager, but still following the standard unix deployment rules.

That's why you have /usr/local/bin, /usr/local/sbin /usr/local/include etc...

/opt on the other hand is for software that doesn't follow this and is deployed in a monolithic fashion. This usually includes commercial and/or cross-platform software that is packaged in the "Windows" style.

  • 10
    I disagree about your monolithic point. The FHS standard says packages installed in /opt subdirectories must have their host specific files be installed outside /opt, respectively under /etc/opt/package for configuration files and /var/opt/package for logs, spool and similar. /opt is actually closer to the unix deployment rules than /usr/local, which put everything under a directory that should be read-only but can't be for obvious reasons. – jlliagre Apr 4 '13 at 9:03
  • 4
    Sure, if I were making an opt package and wanted to claim FHS compliance. Otherwise the standard is more what you'd call "guidelines". Just because NetBeans doesn't use /etc/opt/netbeans isn't going to keep me from putting it in /opt for system-wide or $HOME/.local/opt for a single-user. – jla May 14 '15 at 18:59
  • 1
    @jla I assume your last comment was directed to me so please use @ xxx when replying to someone else that the OP or the reply author. About /etc/opt, the FHS doesn't say it is a recommended location (as a guideline) but a mandatory location. You or Netbeans developer are free to violate that standard as there is no authority to enforce it, but don't tell doing it wrong is the way to go. It is just an unfortunate misunderstanding or deliberate violation. – jlliagre May 22 '15 at 11:15
  • 5
    @jlliagre As an administrator of my system, the FHS is a set of guidelines. The /opt directory is the common sense well-established place to put monolithic /opt/<package> or /opt/<provider> software. When I install a package that wants to use <package|provider>/all/data/required/to/support, it's going into opt/ even if provider fails to follow every detail of the latest FHS. I might send an email or report a bug, but I'm not going to put that monolithic package somewhere else to feel better about FHS on my system. – jla May 27 '15 at 18:04
  • 1
    @jlliagre I've installed lot of stuff in /opt and no file is created in /etc/opt. Should? – erm3nda Jan 26 '16 at 0:38

They are very similar indeed, and the use of one or the other is more a matter of opinion. Linux journal had this point/counterpoint discussion about this exact topic here.

  • 7
    Oh dear. I didn't mean to drag myself into a "holy war". – Patches Apr 18 '11 at 15:01

For me, personally, it's what Bill said in @philfr's link:

On a development system, or a sandbox, having an /opt directory where you can just toss things and see if they work makes a whole lot of sense. I know I'm not going to go through the effort of packaging things myself to try them out. If the app doesn't work out, you can simply rm the /opt/mytestapp directory and that application is history. Packaging may make sense when you're running a large deployment (there are times when I do package apps), but lots of times, it's nice to toss stuff in /opt.

Unfortunately, most make install scripts pushes files into /usr/local instead of just making a symlink there :-/

  • 2
    What would be the point? If you are going to make the symlink anyway, why not just put the original file there in the first place? – Let_Me_Be Apr 18 '11 at 9:54
  • 6
    Just to comment on the make install target pushing files into /usr/local; this functionality is easily changeable by passing a --prefix= command line parameter to the ./configure script, or if there is no ./configure script, you can pass a parameter to the make target like so: make --prefix=/usr install. – Sean C. Apr 18 '11 at 11:45
  • 3
    Is /opt a standard directory included in $PATH? I know /usr/local is. – LawrenceC Apr 18 '11 at 14:13
  • 4
    @Let_Me_Be the benefit would be that it's very easy to keep older versions. Let's say I have 2 versions of 'foo', located in /opt/foo-1.1 and /opt/foo-1.2. When I upgrade, foo symlink in /usr/local/bin points to foo-1.2. If for some reason I need to rollback, I just replace the symlink with one that points to foo-1.1 instead. If 1.2 is okay after several weeks, a quick rm -rf /opt/foo-1.1 removes the older version quickly and cleanly. – pepoluan Apr 18 '11 at 14:41
  • 5
    @ultrasawblade no, it is not. and never should be. after all, according to FHS, /opt must be subdivided into subdirs bearing the name of the package. cramming everything into PATH is a surefire way to disaster. rather, apps should install themselves under /opt, and symlinks their user-invoked programs into /usr/local/bin (or sbin). – pepoluan Apr 18 '11 at 14:45

First, I don't think there is a strict answer; different adminstrators will have different opinions, according to their background. Historically, /usr/local came first; it was the convention in Berkley, IIRC. At one point during the development of System V, if I'm not mistaken (this is all a long time ago, and I didn't take notes), there was a decision or a desire to be able to mount /usr read-only, which meant you couldn't add new software to it; that may have been why /opt was invented. As it happens, there was just so much existing software that did write to /usr that that idea never really got off the ground.

My personal preference is /opt, with a separate subdirectory for each product; this makes removing a product a simple case of rm -fr. But if all of your software is installed via a good package manager, it doesn't matter, and if the software you install doesn't strictly obey these conventions, and writes configurations and such somewhere under /usr, it doesn't matter either, although for the opposite reasons.

  • 1
    """all of your software is installed via a good package manager""" that's impossible unless you use only oft-used software. – Pacerier Nov 1 '17 at 22:21
  • @Pacerier it's possible, it depends what distro you're using. Whatever the software is, it's probably in the Arch User Repository, and if it isn't, a PKGBUILD is relatively easy to write. – StarlitGhost Nov 2 at 10:17

I have a slightly different take on this issue.
While everything in jlliagre's answer is correct, the practical application for me, when deploying software in a cluster, comes down to default environment variables and default reuse of libs.

Simply put - /usr/local and all its child dirs are in the appropriate env vars such as PATH and MANPATH, and /usr/local/lib{,64} are in ldconfig's (/etc/ld.so.conf.d/).

/opt/ OTOH is not — which is both advantageous when requiring multiple versions or conflicting packages to co-exist in the system, but requires some sort of environment management (e.g., environment-modules or software collections), and disadvantageous in that it would potentially "waste" storage space by duplicating shared libraries, as each installation in /opt can be completely self contained.

For the shared nature of /usr/local to work, it is assumed that e.g. binaries are installed directly to /usr/local/bin (and man pages to appropriate /usr/local/share/man/...) rather than /usr/local/app/{bin,share/man,...} etc.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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