Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have been using Linux servers for years now and I keep on being confused by the Filesystem Hierarchy Standard. Usually, I can live with the confusion. But now that I am developing my own software for Linux, I need to understand where it is supposed to be installed by package managers.

I was pretty convinced that /opt was the perfect location for my application. But after having investigate my Debian filesystem, I'm not sure anymore : a lot of softwares are actually installed in /usr/lib ! To name a few : MySQL, MySQLWorkbench, Nautilus, Rythmbox...

According to the FHS, /usr/lib is supposed to contain "Libraries for programming and packages" and "includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts" (See here).

A lot of softwares located in /usr/lib of my debian server are not libraries or internal binaries but full-fledged user executable softwares !

I'm still on track to have my application installed in /opt. But I really would like to understand if this is correct and, above all, why.

Thanks by advance for your kind advices,


share|improve this question
Spot checking, from what I can tell MySQLWorkbench installs only libraries under /usr/lib. What makes you think that there is "full-fledged user executable software" in /usr/lib? –  Mark Wagner Aug 27 '13 at 19:40
The actual shortcut located in the Application menu point to a binary located in /usr/lib, if I remember correctly. –  Eric MORAND Aug 28 '13 at 9:36
You seem confused about where the software you listed is installed. Here are links to listings if the files for MySQL and Nautilus. Notice that the files are split among /etc, /usr/bin, /usr/lib etc. just like FHS says they should be. packages.debian.org/wheezy/i386/mysql-server-5.5/filelist packages.debian.org/wheezy/i386/nautilus/filelist –  sciurus Sep 1 '13 at 1:15
add comment

5 Answers

The difference is that /usr is meant to hold packages installed as part of the system. Packages you get from the Debian/Ubuntu repositories, PPAs, etc., go here. While /opt is meant for unbundled third party applications that are not distributed through the distribution's package distribution process.

If you distribute .deb or .rpm packages, with an eye toward eventually getting your software included in the official repositories, you should install to /usr. Otherwise install to /opt. In either case, your application should be able to be compiled to run in any arbitrary location (e.g. with the help of the GNU autotools).

share|improve this answer
Thanks. Right now, I have no plan to have my app included in the official repository. –  Eric MORAND Aug 28 '13 at 9:38
What about /usr/local, then? Or is that discrete –  Aaron Copley Sep 2 '13 at 15:03
@AaronCopley /usr/local wasn't in scope for this question. But it's meant for third-party software that the local administrator compiles and installs. –  Michael Hampton Sep 2 '13 at 15:04
That is why I asked if it would be considered discrete. –  Aaron Copley Sep 2 '13 at 15:48
add comment

The real key to understanding the Filesystem Heirarchy Standard is knowing that it is designed with network filesystems in mind.

For every machine of the same OS, release, and architecture, you can share /usr via NFS and mount it.
/usr is (re)mounted after the network stack is initialized.

/var <-- local, r/w optimized
/usr <-- can be mounted over network, possibly even read-only!
/opt <-- local, read mostly
/etc <-- local, read mostly
/srv <-- local, r/w optimized

/home <-- either/or
share|improve this answer
Would you mind providing a link for the local/remote and r - r/w standards? –  Captain Giraffe Aug 27 '13 at 20:27
Does this mean that one can have a single /usr "repository" for every Linux server or workstation in a network ? –  Eric MORAND Aug 28 '13 at 9:39
It takes some work, but yes, you can. Back when hard drives where expensive this was the norm for any large rollout. –  Dan Garthwaite Aug 29 '13 at 13:26
@eric-morand From the FHS: "/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY –  Dan Garthwaite Aug 29 '13 at 13:32
Whoops. The above comment was for @CaptainGiraffe –  Dan Garthwaite Aug 29 '13 at 14:04
add comment

I would suggest to avoid installing your app under /opt. Reason 1 : Some distros do not have /opt by default Reason 2 : /usr/lib is a standard path for libraries {If other applications need to use your library you need to add your library path manually to /etc/ldconfig} /opt is more convenient when you have standalone apps which you install manually and you want to know where they are located

One of the reason that fully fledged executables are located under /usr/lib could be that they are used from other scripts. {For example bash scripts cannot use an API directly. for this reason a common trick is to build a "wrapper" around this api and push parameters as script's arguments }

share|improve this answer
I disagree. If he wants to install in /opt, the package manager will create the directory, so that is a non issue. Also, binaries installed in /usr/lib is a bad idea. –  Walter Aug 28 '13 at 1:14
Thanks @Nikolaidis Fotis. But in my case, my app does not contain a public library and will not be used by other applications. –  Eric MORAND Aug 28 '13 at 9:40
add comment

You install your libraries in <prefix>/lib , your binaries in <prefix>/bin, your header files in <prefix>/include, man pages in prefix/[share/]man, pkgconfig files in <prefix>/lib/pkgconfig or <prefix/share/pkgconfig, your cmake .m4 files in <prefix>/share/aclocal

Then let package manager decide on the prefix. If you are distributing rpm's/deb's yourself, /usr is a good choice for a prefix.

./configure --prefix=~/.local/ Should still work, so don't go hardcoding your path anywhere please!

Some libraries are wrapped into some other tool that makes them also executable and usable as a library, but they are still libraries, and not in your $PATH, so it is ok to puth them in /lib I guess.

share|improve this answer
add comment

Please, install it in /opt.

Way too many Linux applications make the same make that Windows developers made in the 90's.

Lets install our stuff in C:\windows so that it is simple and easy to find (and slightly faster). Then came 15 years of DLL hell as different software packages needed different versions of the same libraries (which in Windows didn't have versioning of the the libraries).

Unless you are writing actual system software, put it in /opt, so that people can better track who installed what.

share|improve this answer
This isn't Windows. We have package managers that work and this really isn't much of an issue. –  Michael Hampton Aug 28 '13 at 1:27
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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