Tuxfiles says the following about the Linux directory structure:


This directory contains variable data that changes constantly when the system is running.

FHS on /var says the following:

/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.

They then go on to say that things like logs, mail and the spooler are put in that folder.

Traditionally A stock installation of Apache or Nginx on Ubuntu Linux will place the directory at /var/www/.

It doesn't seem to me like the ideal place to put a directory with files or otherwise content that is supposed to be almost permanent.

Why is it so often put into /var?

More subjectively, is this where it should ideally go, according to the directory structure?

  • 2
    This is a good question that I asked myself often too and arranged with it somehow :). – wolf Sep 7 '12 at 6:48
  • 1
    According to FHS /var/lib/www would have been more suitable... – Nils Sep 7 '12 at 20:21
  • 3
    current FHS says web server root should be somewhere below /srv – LogicDaemon Mar 30 '17 at 7:22
  • /var is for non-executable non-configuration non-owned-by-a-real-user data that can be edited or change (e.g. should live on a rewritable volume). /var/lib is specifically for that type of data that should survive a reboot and not be deleted by a maintenance process, isc-dhcp-server uses /var/lib to store its record of DHCP leases for example. So it would be a logical spot for web server files. – LawrenceC Mar 30 '17 at 15:39
  • @Nils, Why lib? – Pacerier Aug 22 '17 at 5:09

It's actually not the "traditional" location at all. Traditionally, anything you installed after the OS went into /usr/local, and indeed that's the "Classical Apache path layout" (their words) to this day. For a long time, it was /home/httpd.

What you're seeing is that an Apache that has been configured for a particular OS -- whether that's Red Hat Linux, Mac OS X, GNU, etc - will customize the location. Apache's source are well designed for this, in fact if you trace the value for the ServerRoot in the source files, you'll see that it starts out in this file, config.layout:

Some excerpts from that file will show you that there's a lot of variety in the docroot location.

IIRC, /var/www came into my life with the 2000-2001 releases of Red Hat Linux 7.x (not Red Hat Enterprise Linux). For all the reasons you cite above, I thought it didn't make great sense - but the reality is that in the modern era so many other tools and technologies are involved the location moves anyway.

#   Classical Apache path layout.
<Layout Apache>
    prefix:        /usr/local/apache2
    datadir:       ${prefix}

#   GNU standards conforming path layout.
#   See FSF's GNU project `make-stds' document for details.
<Layout GNU>
    exec_prefix:   ${prefix}
    datadir:       ${prefix}/share+

#   Mac OS X Server (Rhapsody)
<Layout Mac OS X Server>
    prefix:        /Local/Library/WebServer
    datadir:       ${prefix}

#   Darwin/Mac OS Layout
<Layout Darwin>
    prefix:        /usr
    datadir:       /Library/WebServer

#   Red Hat Linux 7.x layout
<Layout RedHat>
    prefix:        /usr
    datadir:       /var/www

#   SuSE 6.x layout
<Layout SuSE>
    prefix:        /usr
    datadir:       /usr/local/httpd

#   BSD/OS layout
<Layout BSDI>
    prefix:        /var/www
    datadir:       ${prefix}

#   Solaris 8 Layout
<Layout Solaris>
    prefix:        /usr/apache
    datadir:       /var/apache

Usage of /var/www is confusing only at first sight.

According to the FHS, web server data should go to /srv. That is the main rule.

However, it also says that deciding about the structure of /srv is the sole responsibility of the local administrator! Therefore packages must not put anything into /srv, and the default document root must not be /srv, because the (apache) package does not know what is in /srv and below it. Maybe a subversion repository with clear text password and other things as well. So there must be a default outside of /srv. That default become /var/www.

/var/www is mostly a placeholder. Packages use /usr/share for static HTML content, or /var/lib for dynamic variable content. Many people mistakenly thought that they should then put HTML into /var/www. That is a problem, because packages occasionally use that too. So recently they invented /var/www/html for packages. Hopefully people will not start to use that because then again they have to invent a new directory... and so on.

Summary: you should use /srv and configure your Apache virtual hosts accordingly.

  • 5
    This answer is really valuable. "Hopefully people will not start to use that because then again they have to invent a new directory... and so on." Shows that many administrators should take the time and read up on some basics. (like i am doing right now ;)) – Toastgeraet Aug 15 '16 at 9:09
  • This has already happened in Ubuntu versions. apache document root defaults to /var/www/html i read somewhere that the reason for the change was it being more secure. i cant contest to that as i don't know. I can tell you that i actually won't be using that path. and will continue with the setup that i have been using for a while. I mount a disk specifically for virtual hosts in /websites. I keep a similar structure to cpanel hosting and serve from /websites/vhostname/public_html. In this way i can use the vhost to hold mail or whatever for the specific vhost. – Chris Dec 14 '16 at 10:52
  • Im actually considering partitioning a disk and mounting the partions into the vhost directory for individual vhost backup. which would give me /websites/vhost/backup in each vhost (I run a few and probably will run more at a later date) – Chris Dec 14 '16 at 10:56

While I agree with akond's answer, I think there is a more important aspect to it. Most of the other locations (such as /usr/local) are typically managed by the system (the package manager). /var is usually where files go that are not managed by the package manager (system wide 'data').

I also think the definition from the FHS is a bit more accurate (the data does not have to be "constantly changing"):

/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.

However the FHS also species that www data should be going into /srv

/srv contains site-specific data which is served by this system.

This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed.

The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs.

  • 7
    Errr, the whole point of /usr/local is that its not managed by the package manager. – derobert Sep 7 '12 at 16:06
  • @derobert /usr/local gets used a lot by 3rd party packages (packages not provided by the distro's repo). It's also common for companies who build their own packages to put them in there (though that still falls under packages not provided by distro). This is supported by the FHS as well, see note #27 at the very bottom of pathname.com/fhs/pub/fhs-2.3.html – Patrick Sep 7 '12 at 17:41
  • 3
    /srv/www was the classical path on SuSE-systems (up to SLES10), too. – Nils Sep 7 '12 at 20:19
  • 1
    @nils wait, they were compliant with FHS and then deliberately left it??? sigh – Patrick Sep 7 '12 at 21:40
  • @Patrick yeah, my comment didn't describeit fully , it's at the discretion of the administrator... That could mean using the package manager, stow, completely by hand, or a mix of them ... – derobert Sep 8 '12 at 11:53

The reasons are mostly historical, as others said. /var has been used for system data that changes all the time, for example cache files, logs, runtime data (lock files, for example), mail server storage, printer spooling, etc. Basically for all stuff that can't be put in /usr (because it contains local data), are not third-party programs which go in /opt, and is not discard-able and volatile as these go in /tmp.

As Unix/Linux developed, it became messy place with a hodge-podge of various dissimilar directories put together. There has been a tendency in recent years to move some things out of there, particularly content served by the machine (which now as per [Filesystem Hierarchy Standard 2.3, p.15] should go in /srv, not in /var/www).

Similar thing happened to /var/run a few years back -- with the concentrated effort of several distributions, it was moved from /var/run into /run which fused together the functions of the previously used /var/lock, /var/run and /dev/shm.

From my experience (I am a web developer) web site content is far from stable. Even in case of html files (nevermind dynamically generated content) they are subject to constant changes (amendments, omissions, etc.).

So from my point of view, they are variables. Thus, they are perfectly suited in the /var directory and there is nothing wrong with that.

  • 4
    I would disagree. I still don't see HTML files as "constantly changing". Changes made to them are deliberate and would ideally be checked into a revision-control for change tracking. – jonallard Sep 8 '12 at 20:45
  • 2
    Changes to the Mysql database are also deliberate, yet database files are located in /var/db. Does not bother you? – akond Sep 8 '12 at 21:03
  • 5
    Sure does, but I would argue that on the continuum from variable to constant, the DB would be more variable than the HTML/whatever/web application, since there are fewer versions of the web pages than there is of the database. The pages having relatively few different versions, I would not put in /var. But I think it is a matter of opinion and debate rather than hard facts. – jonallard Sep 8 '12 at 21:13
  • 1
    What would you say if I show you a database that has not been changed for two years? – akond Sep 8 '12 at 21:26
  • 1
    By the arguments given here, home directories belong in /var. For that matter, so does /usr because that gets updated constantly for security patches, etc. /var is for files that "frequently" change, which allows one to mount a filesystem optimised for heavy writes of small files. Arguing that a database doesn't belong in in /var doesn't strengthen the case that websites do, it really makes the case that they don't. Websites are heavy-read and garner no benefit from being on /var, and may actually slow down essential system processes such as logging and email. – Duncan Aug 22 '15 at 10:52

IIRC, in the olden days, we always mounted /var as it's own filesystem (separate disk or slice of a disk).

One of the reasons for this this, as others have stated, is that there is heavy reading/writing to that filesystem (logs/et al). Having a separate disk/slice means it can be better tuned for this type of I/O (versus mostly read on /, /usr, etc...).

The other reason is that back in those days, if your system crashed during a write operation, there was a very good chance that your root filesystem could get corrupted leaving it in a hard to repair state. Thus the need for separation from /.

Filesystem & disk technology has greatly improved over time, so this is a far less likely occurrence.

  • /var as a separate partition is still good practice if you don't want to bring down your machine when your logs go wild, due to / being full – Duncan Aug 22 '15 at 10:54

/var is a decent choice for a user-neutral "base" location for multiuser access, in the event you have a website with multiple virtual hosts running that allows FTP or other uploads, i.e. if you are a webhost or similar.

/home is possibly not optimum because bad things could happen to other user shell accounts if a unthinking or malicious user uploads to the /home partition limit (assuming traditional setup of /var, /home, etc. being on separate partitions) it can affect other user accounts.

Of course I think /srv is better for this but /var's been around longer in the UNIX tradition.

  • Distributions and distributed packages should adhere to the FHS. The end "user" (sysadmin if its a server) can do as she wants and put the web site wherever. I've been putting websites in /home/pub or /home/web since before there was /srv. But if I were to distribute a web server software project today, /srv/www or whatever FHS says would be the default, though the admin can change it. – Skaperen Sep 9 '12 at 2:22
  • @ultrasawblade, Why not /home/http? – Pacerier Jan 22 '15 at 6:47

What I'd like to add here is that putting the web "root" in /usr conflicts the part of the FHS that indicates /usr as being share-able and read only, since different web servers, even on the same "cluster" can have different files that contain different configurations, and this does not make it ideal for /usr.

In addition, some web applications (MediaWiki and PhpBB to name the ones off the top of my head) expect a write-able location under the web directory tree for attachments/media file uploads. So putting the web tree under /usr would conflict if you wish to adhere to the read-only /usr definition.

Apache web server have default website under /var/www/ but it is suggesting to put other websites under /srv/

I noticed this on Ubuntu Server 14.04 LTS. Its default apache2.conf file contains commented block:

#<Directory /srv/>
#   Options Indexes FollowSymLinks
#   AllowOverride None
#   Require all granted

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.