I've always configured Apache like this:

/etc/httpd/conf/httpd.conf (Main Apache config)

<Directory />
   Options None
   AllowOverride None
   Order deny,allow
   Deny from all 

<Directory "/var/www/html">
    Options None
    AllowOverride None
    Order deny,allow
    Deny from all

Virtualhosts config

<VirtualHost *:80>
        ServerName xxxxx.co.uk
        ServerAlias xxxxx.co.uk xxxxx
        DocumentRoot /var/www/html/xxxxx.co.uk   
        ErrorLog /var/www/log/xxxxx.co.uk
        <Directory "/var/www/html/xxxxx.co.uk">
                AllowOverride None
                Options -Indexes -FollowSymLinks
                Order Allow,Deny
                Allow from all

I've noticed that some people seem to create a specific folder for web content and logs, i.e


I wonder if anyone could throw any light onto why that is? Is it more secure to do it like this? Are there any other reasons to move web content content and logs out of the /var/..... path?

Thanks in advance :-)

  • That might just be how people have mounted / partitioned their drives. /Var should be for data so I believe /var/www is correct for websites and /var/log/apache2 is correct place for apache logs. Why create a future maintenance problem by moving it to a non standard place?
    – flurdy
    Apr 17, 2012 at 18:53
  • RHEL/CentOS stores logs in /var/log/httpd, not /var/log/apache2 -- the latter tends to be found in the Debian ecosystem.
    – Charles
    Apr 17, 2012 at 19:24
  • 1
    possible duplicate of Linux FHS: /srv vs /var ... where do I put stuff? Apr 17, 2012 at 20:51

4 Answers 4


I addition to Mike's point about FHS, here's this discussion from an Ubuntu forum:


The best comment is:

/var is an older convention. It was meant for data that changes over time ("variable data") such as caches, spool, logs, all sorts of housekeeping and administration files, while "user data" would be in home directories, ... but at some point, probably by lack of any other suitable place, /var become also the place to "data" that daemons would serve to other systems and users (such as databases and web pages). Granted, those files would also 'change over time' but I agree there's a difference between a website and a system log.

Debian still defaults to /var for data, but probably most 'old' linuxes do (eg Redhat) and most documentation assumes /var for this sort of stuff as well, although I've seen examples of /srv as data directory in some (less traditional) applications' admin guides.

FWIW, CentOS 6 has a /srv directory, but it's empty, and Apache, for a prime example, defaults to /var/www for the root directory. One can make the case that /srv/logs in your example should properly be placed in /var as is customary, because logs aren't things being served by your machine.

  • What I did wonder however is whether or not there is any particular security benefit to placing 'serveable' data in /srv/html/xxx rather than /var/www/html/xxx?
    – leftcase
    Apr 17, 2012 at 19:16
  • I don't believe there's an additional benefit with /srv that can't be achieved with /var. It's more about neatness and categorization: web assets obviously don't belong in /usr, /lib and so on, and it's not specific to one user so /home doesn't work, so let's stick it in /var, even though we had though of /var as logs, spools, etc., so /var doesn't quite work either, so let's use a new thing called /srv. Yeah, you can mount /srv in a particular way as a separate filesystem, but you can do something similar with whatever bit of /var you're using as your Apache root.
    – cjc
    Apr 17, 2012 at 19:26

My understanding is that /var/www has been the common practice for ages, and /srv is part of a filesystem standardization effort. /var/www is the past, defacto convention, and we're in a transitional period where the old convention is being gradually phased out in favor of the new convention.

The first step in the transition for many distributions is often to create /srv and fill it with symlinks, for instance /srv/www -> /var/www. At some point in the future I would expect to see distributions reverse this, at which point the files would live under /srv and the symlink would be /var/www -> /srv/www. Further in the future, /var/www would presumably go away altogether.

  • what filesystem standardization effort? CentOS 7 still has an empty /srv folder and no /var/www folder, can't find any info about what is actually supposed to be happening with this convention
    – xref
    Aug 19, 2015 at 23:36
  • 9 years later... /srv is finally consolidated by 2015's FHS 3. But... /var/www might not go away: as software such as Apache and Nginx must not change user files at /srv, their default "It works!" pages are still placed at /var/www. But for your stuff, /srv is the way!
    – MestreLion
    Nov 23, 2021 at 5:43

You can take a look at the following


I use /srv also. It's more of that's how I do it and prefer it that why type of thing though.

  • That's interesting. I'm still a little confused about why people store logs in /srv/ too though if it's generally for serving files. I've got to set up a couple of new LAMP stacks shortly and I came across a couple of posts mentioning /srv/. It hasn't really occurred to me before to move data to be served out of /var/www/html/xxx.
    – leftcase
    Apr 17, 2012 at 19:13
  • 1
    I break all my vhosts up /srv/www/vhost/html all my logs still go in /var/log. I believe it's all a matter of what you want to do as a sys admin really. As long as it's documented well others will know what is going on.
    – Mike
    Apr 17, 2012 at 21:04

When you are dealing with really big applications, usually serving data within a cluster, you can use different backends (RAID, NAS...) for /srv and /var, with two additional benefits:

  • Your backup, replication and snapshot policies can be different for /srv (real data) and /var (logs, temps...)

  • Probably, the access to data in /var is sequential, while acces to /srv tends to be more random. You can put /srv in a faster backend (NAS with big caches or SSDs) and /var in cheaper local disks.

It could be done mixing your real data inside /var, but this way is much more clear and easier to manage.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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