Apache giving me 403 on Virtual Host











up vote
1
down vote

favorite












I have been trying to get to grips with Apache in CentOS 7.



I have set up two virtual hosts and created basic index.html pages as follows:



/var/www/domainA/public_html/index.html



/var/www/domainB/public_html/index.html


Both hosts have permissions as follows:



DomainA:



public_html -> jonathan:jonathan

index.html -> root:root


DomainB:



public_html -> jonathan:jonathan

index.html -> root:root


Now, what is happening is DomainA's index.html page is being served up fine, but domain B's index.html gives me a 403 Forbidden.



DomainB's error.log gives me this:



AH00132: file permissions deny server access: /var/www/DomainB/public_html/index.html


Why is this happening? It makes me very sad.






centos apache-httpd apache-virtualhost







share|improve this question




















  • 1




    ¿What filesystem permissions do you have in each directory?
    – motilio
    May 4 '15 at 20:18






  • 1




    To expand on motilio's comment: please show us the output of ls -ld on all public_html and index.html files and directories, as well as on DomainA and DomainB.
    – dhag
    May 4 '15 at 20:23






  • 1




    As i was getting the details of the filesystem permissions, i stumbled across the ls -Z command. This highlighted the fact that the working had the httpd_sys_content_t context but the non-working domain had something like user_root_t context. I set this to be httpd_sys_content_t and both domains are now working. Thanks for your help fellas.
    – jonnyknowsbest
    May 6 '15 at 7:57

















up vote
1
down vote

favorite












I have been trying to get to grips with Apache in CentOS 7.



I have set up two virtual hosts and created basic index.html pages as follows:



/var/www/domainA/public_html/index.html



/var/www/domainB/public_html/index.html


Both hosts have permissions as follows:



DomainA:



public_html -> jonathan:jonathan

index.html -> root:root


DomainB:



public_html -> jonathan:jonathan

index.html -> root:root


Now, what is happening is DomainA's index.html page is being served up fine, but domain B's index.html gives me a 403 Forbidden.



DomainB's error.log gives me this:



AH00132: file permissions deny server access: /var/www/DomainB/public_html/index.html


Why is this happening? It makes me very sad.






centos apache-httpd apache-virtualhost







share|improve this question




















  • 1




    ¿What filesystem permissions do you have in each directory?
    – motilio
    May 4 '15 at 20:18






  • 1




    To expand on motilio's comment: please show us the output of ls -ld on all public_html and index.html files and directories, as well as on DomainA and DomainB.
    – dhag
    May 4 '15 at 20:23






  • 1




    As i was getting the details of the filesystem permissions, i stumbled across the ls -Z command. This highlighted the fact that the working had the httpd_sys_content_t context but the non-working domain had something like user_root_t context. I set this to be httpd_sys_content_t and both domains are now working. Thanks for your help fellas.
    – jonnyknowsbest
    May 6 '15 at 7:57















up vote
1
down vote

favorite









up vote
1
down vote

favorite











I have been trying to get to grips with Apache in CentOS 7.



I have set up two virtual hosts and created basic index.html pages as follows:



/var/www/domainA/public_html/index.html



/var/www/domainB/public_html/index.html


Both hosts have permissions as follows:



DomainA:



public_html -> jonathan:jonathan

index.html -> root:root


DomainB:



public_html -> jonathan:jonathan

index.html -> root:root


Now, what is happening is DomainA's index.html page is being served up fine, but domain B's index.html gives me a 403 Forbidden.



DomainB's error.log gives me this:



AH00132: file permissions deny server access: /var/www/DomainB/public_html/index.html


Why is this happening? It makes me very sad.






centos apache-httpd apache-virtualhost







share|improve this question















I have been trying to get to grips with Apache in CentOS 7.



I have set up two virtual hosts and created basic index.html pages as follows:



/var/www/domainA/public_html/index.html



/var/www/domainB/public_html/index.html


Both hosts have permissions as follows:



DomainA:



public_html -> jonathan:jonathan

index.html -> root:root


DomainB:



public_html -> jonathan:jonathan

index.html -> root:root


Now, what is happening is DomainA's index.html page is being served up fine, but domain B's index.html gives me a 403 Forbidden.



DomainB's error.log gives me this:



AH00132: file permissions deny server access: /var/www/DomainB/public_html/index.html


Why is this happening? It makes me very sad.






centos apache-httpd apache-virtualhost




centos apache-httpd apache-virtualhost






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 10 '16 at 12:47









Jeff Schaller

37.5k1052121




37.5k1052121










asked May 4 '15 at 19:58









jonnyknowsbest

1264




1264








  • 1




    ¿What filesystem permissions do you have in each directory?
    – motilio
    May 4 '15 at 20:18






  • 1




    To expand on motilio's comment: please show us the output of ls -ld on all public_html and index.html files and directories, as well as on DomainA and DomainB.
    – dhag
    May 4 '15 at 20:23






  • 1




    As i was getting the details of the filesystem permissions, i stumbled across the ls -Z command. This highlighted the fact that the working had the httpd_sys_content_t context but the non-working domain had something like user_root_t context. I set this to be httpd_sys_content_t and both domains are now working. Thanks for your help fellas.
    – jonnyknowsbest
    May 6 '15 at 7:57
















  • 1




    ¿What filesystem permissions do you have in each directory?
    – motilio
    May 4 '15 at 20:18






  • 1




    To expand on motilio's comment: please show us the output of ls -ld on all public_html and index.html files and directories, as well as on DomainA and DomainB.
    – dhag
    May 4 '15 at 20:23






  • 1




    As i was getting the details of the filesystem permissions, i stumbled across the ls -Z command. This highlighted the fact that the working had the httpd_sys_content_t context but the non-working domain had something like user_root_t context. I set this to be httpd_sys_content_t and both domains are now working. Thanks for your help fellas.
    – jonnyknowsbest
    May 6 '15 at 7:57










1




1




¿What filesystem permissions do you have in each directory?
– motilio
May 4 '15 at 20:18




¿What filesystem permissions do you have in each directory?
– motilio
May 4 '15 at 20:18




1




1




To expand on motilio's comment: please show us the output of ls -ld on all public_html and index.html files and directories, as well as on DomainA and DomainB.
– dhag
May 4 '15 at 20:23




To expand on motilio's comment: please show us the output of ls -ld on all public_html and index.html files and directories, as well as on DomainA and DomainB.
– dhag
May 4 '15 at 20:23




1




1




As i was getting the details of the filesystem permissions, i stumbled across the ls -Z command. This highlighted the fact that the working had the httpd_sys_content_t context but the non-working domain had something like user_root_t context. I set this to be httpd_sys_content_t and both domains are now working. Thanks for your help fellas.
– jonnyknowsbest
May 6 '15 at 7:57






As i was getting the details of the filesystem permissions, i stumbled across the ls -Z command. This highlighted the fact that the working had the httpd_sys_content_t context but the non-working domain had something like user_root_t context. I set this to be httpd_sys_content_t and both domains are now working. Thanks for your help fellas.
– jonnyknowsbest
May 6 '15 at 7:57












2 Answers
2






active

oldest

votes

















up vote
2
down vote













The issue turned out not to be file /folder permissions as such, but the security context of the non-working domain.



From my limited understanding, in order for Apache to serve up files, the files / folders need to be configured to run under the httpd_sys_content_d context.



My 'mistake' was the non-working domain had been mv'd into the Apache content folder from my Development area and did not have the correct security context so Apache could not serve up the files. This was confirmed by running ls -Z on the public_html folder and subfolders.



I used chcon -R -t httpd_sys_content_t public_html/ to set the correct security context and now Apache is serving up everything.






share|improve this answer





















  • chcon -R -t httpd_sys_content_t Did the trick
    – Michel
    Dec 21 '16 at 12:37


















up vote
0
down vote













chcon -R -t httpd_sys_content_t <Your_Document_Root_Dir>



Should do the trick






share|improve this answer








New contributor




Pedro Marthon is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 3




    Could you please describe what this command does on CentOS?
    – Kusalananda
    2 days ago






  • 1




    Note also that chcon -R -t httpd_sys_content_t public_html was described in the other answer, 3 years ago.
    – Jeff Schaller
    2 days ago











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f200384%2fapache-giving-me-403-on-virtual-host%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote













The issue turned out not to be file /folder permissions as such, but the security context of the non-working domain.



From my limited understanding, in order for Apache to serve up files, the files / folders need to be configured to run under the httpd_sys_content_d context.



My 'mistake' was the non-working domain had been mv'd into the Apache content folder from my Development area and did not have the correct security context so Apache could not serve up the files. This was confirmed by running ls -Z on the public_html folder and subfolders.



I used chcon -R -t httpd_sys_content_t public_html/ to set the correct security context and now Apache is serving up everything.






share|improve this answer





















  • chcon -R -t httpd_sys_content_t Did the trick
    – Michel
    Dec 21 '16 at 12:37















up vote
2
down vote













The issue turned out not to be file /folder permissions as such, but the security context of the non-working domain.



From my limited understanding, in order for Apache to serve up files, the files / folders need to be configured to run under the httpd_sys_content_d context.



My 'mistake' was the non-working domain had been mv'd into the Apache content folder from my Development area and did not have the correct security context so Apache could not serve up the files. This was confirmed by running ls -Z on the public_html folder and subfolders.



I used chcon -R -t httpd_sys_content_t public_html/ to set the correct security context and now Apache is serving up everything.






share|improve this answer





















  • chcon -R -t httpd_sys_content_t Did the trick
    – Michel
    Dec 21 '16 at 12:37













up vote
2
down vote










up vote
2
down vote









The issue turned out not to be file /folder permissions as such, but the security context of the non-working domain.



From my limited understanding, in order for Apache to serve up files, the files / folders need to be configured to run under the httpd_sys_content_d context.



My 'mistake' was the non-working domain had been mv'd into the Apache content folder from my Development area and did not have the correct security context so Apache could not serve up the files. This was confirmed by running ls -Z on the public_html folder and subfolders.



I used chcon -R -t httpd_sys_content_t public_html/ to set the correct security context and now Apache is serving up everything.






share|improve this answer












The issue turned out not to be file /folder permissions as such, but the security context of the non-working domain.



From my limited understanding, in order for Apache to serve up files, the files / folders need to be configured to run under the httpd_sys_content_d context.



My 'mistake' was the non-working domain had been mv'd into the Apache content folder from my Development area and did not have the correct security context so Apache could not serve up the files. This was confirmed by running ls -Z on the public_html folder and subfolders.



I used chcon -R -t httpd_sys_content_t public_html/ to set the correct security context and now Apache is serving up everything.







share|improve this answer












share|improve this answer



share|improve this answer










answered May 6 '15 at 8:05









jonnyknowsbest

1264




1264












  • chcon -R -t httpd_sys_content_t Did the trick
    – Michel
    Dec 21 '16 at 12:37


















  • chcon -R -t httpd_sys_content_t Did the trick
    – Michel
    Dec 21 '16 at 12:37
















chcon -R -t httpd_sys_content_t Did the trick
– Michel
Dec 21 '16 at 12:37




chcon -R -t httpd_sys_content_t Did the trick
– Michel
Dec 21 '16 at 12:37












up vote
0
down vote













chcon -R -t httpd_sys_content_t <Your_Document_Root_Dir>



Should do the trick






share|improve this answer








New contributor




Pedro Marthon is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 3




    Could you please describe what this command does on CentOS?
    – Kusalananda
    2 days ago






  • 1




    Note also that chcon -R -t httpd_sys_content_t public_html was described in the other answer, 3 years ago.
    – Jeff Schaller
    2 days ago















up vote
0
down vote













chcon -R -t httpd_sys_content_t <Your_Document_Root_Dir>



Should do the trick






share|improve this answer








New contributor




Pedro Marthon is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 3




    Could you please describe what this command does on CentOS?
    – Kusalananda
    2 days ago






  • 1




    Note also that chcon -R -t httpd_sys_content_t public_html was described in the other answer, 3 years ago.
    – Jeff Schaller
    2 days ago













up vote
0
down vote










up vote
0
down vote









chcon -R -t httpd_sys_content_t <Your_Document_Root_Dir>



Should do the trick






share|improve this answer








New contributor




Pedro Marthon is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









chcon -R -t httpd_sys_content_t <Your_Document_Root_Dir>



Should do the trick







share|improve this answer








New contributor




Pedro Marthon is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer






New contributor




Pedro Marthon is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered 2 days ago









Pedro Marthon

1




1




New contributor




Pedro Marthon is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Pedro Marthon is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Pedro Marthon is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 3




    Could you please describe what this command does on CentOS?
    – Kusalananda
    2 days ago






  • 1




    Note also that chcon -R -t httpd_sys_content_t public_html was described in the other answer, 3 years ago.
    – Jeff Schaller
    2 days ago














  • 3




    Could you please describe what this command does on CentOS?
    – Kusalananda
    2 days ago






  • 1




    Note also that chcon -R -t httpd_sys_content_t public_html was described in the other answer, 3 years ago.
    – Jeff Schaller
    2 days ago








3




3




Could you please describe what this command does on CentOS?
– Kusalananda
2 days ago




Could you please describe what this command does on CentOS?
– Kusalananda
2 days ago




1




1




Note also that chcon -R -t httpd_sys_content_t public_html was described in the other answer, 3 years ago.
– Jeff Schaller
2 days ago




Note also that chcon -R -t httpd_sys_content_t public_html was described in the other answer, 3 years ago.
– Jeff Schaller
2 days ago


















draft saved

draft discarded




















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f200384%2fapache-giving-me-403-on-virtual-host%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

Accessing regular linux commands in Huawei's Dopra Linux

Image
4 Backstory: I have a Huawei HG8245 router in my house and I want to change the default username/password. I've tried following this guide but the config file always gets reset. My ISP isn't helping either so I'm looking for other ways to accomplish this. The router has telnet access so this seems like a way to change the credentials. The first shell I gain access to looks like this: WAP> Pressing "?" gives me a list of available commands which I've pasted here, the two interesting ones are "su" and "shell". I can't seem to get su access, even after logging in as root (challenge password prompt, and then nothing happens), but shell gives me a proper linux shell. WAP>shell BusyBox v1.18.4 (2017-12-26 17:06:34 CST) built-in shell (ash) Enter 'hel...
Read more

Can't connect RFCOMM socket: Host is down

Image
up vote 3 down vote favorite I have bluez 5.4.3 and I am attempting to communicate with a ble device through minicom. These two deceives (my computer and a bluno nano) are alreadt paired and this has been my method so far. #bluetoothctl # pair xx:xx:xx:xx:xx:xx # exit Everything is working well so far then... #sudo rfcomm connect /dev/rfcomm0 xx:xx:xx:xx:xx:xx 1 & [1] 3665 Can't connect RFCOMM socket: Host is down Does anyone know how to resolve this issue? Any help would be very much appreciated. bluetooth bluez share | improve this question asked Feb 9 '17 at 18:46 Brandon Knape 46 2 ...
Read more

Kernel panic - not syncing: Fatal Exception in Interrupt

Image
0 Every day this error occured on my pc, kernel panic error on interrupt, what will be the problem? linux-mint share asked 6 mins ago Vinod Selvin Vinod Selvin 1 1 New contributor Vinod Selvin is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. add a comment ...
Read more