Configuring a <Directory>

Use of the <Directory> configuration directive is, in general, straightforward. However, there are a few caveats of which to be aware.

First, it is not necessary to nest <Directory>; the daemon will not let one do this, in fact. The daemon will determine automatically the relations of <Directory> paths, depending on the path given and surrounding configuration context.

Always use the normal, absolute path for a <Directory> section, regardless of whether that directory will eventually be accessed during a session which has been chroot'd, as for <Anonymous> or DefaultRooted sessions. There are two allowed exceptions to the rule of using absolute paths: if the path has a ~ prefix, or if the <Directory> occurs within a <Anonymous> section. In the latter case, the path may be relative (i.e. does not need to start with a /), in which case the path will be relative to the directory to which anonymous sessions are restricted.

If the name of the directory contains spaces, you should enclose the entire directory name in quotations, e.g.: 

  <Directory "/path/to/My Directory">

As noted in the documentation, use of a /* suffix on a path will change the effect of a <Directory> section slightly. For example: 

  <Directory /path/to/dir>
applies the section's configuration directives to the dir directory and its contents, while: 
  <Directory /path/to/dir/*>
applies the section's configuration directives only to the contents of dir, not to the directory itself. This is a small distinction, but it can often cause misconfigurations. In general, unless you know what you're doing, it's best not to use a /* suffix.

Also, a * within a path, such as: 

  <Directory /path/to/*/dir>
will only match that single directory level, and will not match multiple directory levels. This means that the above <Directory> will match: 
  /path/to/a/dir
  /path/to/b/dir
because * will match the a/ and b/, as they are on the same level in the path as *. However, the following paths will not match: 
  /path/to/some/other/dir
  /path/to/some/other/level/dir
since * does not expand to some/other/ or /some/other/level/; they cover multiple levels.

There is another case about which the administrator should know: for the purposes of handling the APPE, RETR, STOR, and STOU FTP commands, the daemon will match a <Directory> path with the filename appended. As above, in most cases this will not matter much. However, consider the case where the administrator specifically wants to use the trailing /*, as when she wants a particular <Limit> to apply to all subdirectories of a given directory, but not to that directory itself. For example, the administrators wishes to block anonymous uploads everywhere except for subdirectories of upload/: 

  <Anonymous ~ftp>
    User ftp
    Group ftp

    UserAlias anonymous ftp

    <Limit WRITE>
      DenyAll
    </Limit>

    <Directory upload/*>
      <Limit STOR>
        AllowAll
      </Limit>
    </Directory>
  </Anonymous>
This configuration looks like it should work, allowing files to be uploaded only to subdirectories of upload/, but not to the upload/ directory itself. As described above, though, the daemon will append the filename being uploaded via STOR to the path used when looking up <Directory>, meaning that upload/filename will match upload/*, and allow files to be uploaded into upload/. In this particular case, then, what is wanted is to use this <Directory> pattern: 
    <Directory upload/*/*>
      <Limit STOR>
        AllowAll
      </Limit>
    </Directory>
which will achieve the desired effect of allowing uploads only in subdirectories of the given directory, upload/.

Also, it is good to keep in mind the similarity between a <Directory> section and a .ftpaccess file. In some cases, using .ftpaccess files might be more convenient. The AllowOverride configuration directive (which first appeared in the 1.2.7rc1 release) will provide fine-grained control over when .ftpaccess files will be honored.

Last Updated: $Date$