I have several websites installed in subdirectories on my Mac laptop at /Users/davidnorman/Sites where I pointed the OS-included installation of Apache to use as my DocumentRoot. This weekend, I switched one of the sites installed in a subdirectory to use the root of my DocumentRoot as the source of the "File system path" setting at admin/settings/file-system.

Since the private setting, outside the expected installation of Drupal is supposed to be able to support writing files, I had to chmod my DocumentRoot directory as 777 to get the setting to save, even though I just wanted to read some files there, not write. Note: Though I did not do it recursively, chmodding the root of your web tree as 777 is is a BAD thing in most circumstances.

After setting the private file system path in the subdirectory Drupal 6 install, none of the PHP scripts anywhere in my DocumentRoot worked anymore. The chmod wasn't the problem though. One of the reasons the file system path has to be writable is that Drupal adds a .htaccess file to that directory which effectively disables script execution for security's sake.

The result in the Apache /var/log/apache2/error_log was simply a mysterious, unhelpful bit:

[Sat Jan 08 21:08:16 2011] [error] [client 127.0.0.1] Attempt to serve directory: /Users/davidnorman/Sites/

That is the error I would get regardless of whether I tried to load http://localhost/, http://localhost/phpinfo.php, or http://localhost/drupalinstallation/.

The solution: Remove the .htaccess file that Drupal automatically added at /Users/davidnorman/Sites/.htaccess. Also, pick a different subdirectory, other than the web root for private files in your subdirectory installs of Drupal.

Let this serve as a reminder that chmodding your web directory, even in your sandbox, to 777 is a bad idea, and that the root of your web tree is not a good dumping ground for private file system path settings on subdirectory Drupal installations.