114

Tuxfiles says the following about the Linux directory structure:

/var:

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 or Arch 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?

6
  • 3
    This is a good question that I asked myself often too and arranged with it somehow :).
    – numchrun
    Sep 7, 2012 at 6:48
  • 1
    According to FHS /var/lib/www would have been more suitable...
    – Nils
    Sep 7, 2012 at 20:21
  • 4
    current FHS says web server root should be somewhere below /srv
    – LogicDaemon
    Mar 30, 2017 at 7:22
  • 1
    /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, 2017 at 15:39
  • 1
    @Nils, Why lib?
    – Pacerier
    Aug 22, 2017 at 5:09

9 Answers 9

Reset to default
63

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.

3
  • 13
    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, 2016 at 9:09
  • 1
    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.
    – CodingInTheUK
    Dec 14, 2016 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)
    – CodingInTheUK
    Dec 14, 2016 at 10:56
42

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
26

While I agree with akond's answer, I think there is a more important aspect to it. Most of the other locations 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](http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A) 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.

10
  • 8
    Errr, the whole point of /usr/local is that its not managed by the package manager.
    – derobert
    Sep 7, 2012 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
    – phemmer
    Sep 7, 2012 at 17:41
  • 3
    /srv/www was the classical path on SuSE-systems (up to SLES10), too.
    – Nils
    Sep 7, 2012 at 20:19
  • 1
    @nils wait, they were compliant with FHS and then deliberately left it??? sigh
    – phemmer
    Sep 7, 2012 at 21:40
  • 1
    @Patrick so it is - I was pretty astonished when I realized this. Probably they wanted to be more like the other Linux-variants...
    – Nils
    Sep 8, 2012 at 19:28
14

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.

7

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.

6
  • 7
    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, 2012 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, 2012 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, 2012 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, 2012 at 21:26
  • 2
    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, 2015 at 10:52
6

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.

1
  • 1
    /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, 2015 at 10:54
3

/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.

2
  • 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, 2012 at 2:22
  • @ultrasawblade, Why not /home/http?
    – Pacerier
    Jan 22, 2015 at 6:47
2

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
#</Directory>
1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .