Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a strange problem when adding a sub-domain to our virtual server. I have done similar sub-domains before and they have worked fine.

When I try to access the sub-domain I get an 403 Forbidden error.

I checked the error logs and have the following error:

pcfg_openfile: unable to check htaccess file, ensure it is readable

I've searched Google and could only find solutions regarding file and folder permissions, that I have checked and the solution isn't solved. I also saw problems with Frontpage Extensions, but that's not installed on the server.


Forgot to say that there isn't a .htaccess file in the directory of the sub-domain

Edit #2

Still not been able to find a solution on this. Only things I have been able to find out is:

  • It doesn't seem to be a problem with any .htaccess files (I've tried creating blank ones, with correct user privileges).
  • It doesn't seem to be a problem with any folder permissions as they are all set correct.
  • There isn't a problem with the way the sub-domain has been set up, as I've tried pointing the DocumentRoot to another folder and it worked fine. I've also done sub-domains fine before with no problem.

Edit #3

Find out more information. I don't think it can be a file permission problem now, because if I access it by going to the server ip and then the directory where the site is hosted it all works fine (minus the stylesheets & images, which is just down to how they are linked)

share|improve this question

Are you using the Apache ITK MPM? Version 2.2.17 fixes a bug that can cause 403 errors (see the changelog).

I was experiencing the same problem when using the AssignUserId directive. It went away when I gave the files and folders world-readable/executable permissions.

share|improve this answer

What user did you edit the .htaccess file as? Can you list the permissions on this file? Its possibly because the user apache is running as can't read the file.

share|improve this answer
There isn't an .htaccess file for that sub-domain. That's the confusing part! – Josh Feb 11 '11 at 21:11
Hi Josh- reading online, found numberous solutions, such as here:… – AliGibbs Feb 12 '11 at 0:06
Thanks for the suggestion, but FrontPage extensions isn't on the server. – Josh Feb 12 '11 at 14:52

You need to change the permissions on the folder referenced. The folder needs to be executable for the user that owns the apache process.

share|improve this answer
I have already tried that, and it didn't change anything. – Josh Feb 11 '11 at 21:11

Try creating a blank htaccess file in that directory with the correct permissions as it may for some strange reason be expecting to read one but can't

The 403 error may be due to not allowing directory indexing for that directory

share|improve this answer
Thanks for the suggestion, but it didn't work unfortunately. – Josh Feb 12 '11 at 14:48
did you also make sure it had permissions that the webserver could read? also try adding the line Options +Indexes to that .htaccess file to see if it fixes the 403 – anthonysomerset Feb 25 '11 at 9:39

Try to log in as apache user (su - apache) and enshure this directory is readable by it.

share|improve this answer
Is there anyway I can check that without logging in as the user apache? – Josh Feb 14 '11 at 15:51
@Josh You can look at the directory's ownership and permissions, but suing to the user and testing directly is probably just as quick :) – voretaq7 Jul 24 '12 at 16:46

I experienced a similar problem : my "/var/www" folder was unaccessible by Apache. My webserver is running inside a VirtualBox host, and the www folder is shared between the guest (SLES11) and the host (Windows). The problem was that the www folder is a VirtualBox file system mounting point, and the linux Apache user (nobody) was not authorized to browse the mounting point.

To solve this, I added the nobody user into the VBOXFS group :

$>usermod -G vboxsf nobody

I have to restart the guest for this modification to be reflected onto Apache, and now it works.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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