I was checking the /var/log/httpd/error_log on my server and I found a number of critical messages saying:

...permission denied /home/foo/public_html/bar/baz/.htaccess
unable to check htaccess file, ensure it is readable

Usually, such a message means, obviously, that there's a .htaccess file in the directory with the wrong permissions or the directory has the wrong permissions. However, in the cases I saw, there was no such file at all. There were files in the directory, and they were perfectly readable from the web, so the directory permissions are fine. I double-checked the whole path to be sure, and they are all 755.

Any idea why this would be an error at all?

Scott

There should be a setting httpd.conf that deals with .htaccess files. In short, if someone asks for that file Apache won't even go out and look - it will simply deny access up front. Trying to access .htaccess files is a very common automated attack/scan - it's just part of the background static of being on the Internet and shouldn't be anything major to worry about.

Thanks Gort. Yes, it is possible to turn off .htaccess files entirely (and improve performance as well), but I don't want to do that. I have many users and I want them to be able to protect or unprotect directories without intervention by the sysadmin (me). If they get the permissions wrong, I can fix it, but it's annoying to be told the permissions on a file are wrong when the file doesn't even exist.

Hmm. Your last sentence is intriguing, though. Are you saying that someone might be trying to GET the .htaccess file specifically? Shouldn't I see that in the access log, with a 404 as the return status?

Scott

You should see a GET in your logs, but it wouldn't give a 404, even if the file is not there. Because .htacess is "special" and apache has special security on .ht* files specifically, if you try to GET a .ht* file apache will just outright deny the request with a 403 error. Apache doesn't even tell the client whether the .ht* file is there or not.