Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've got a brand new CentOS 6 installation, which has a symlink in the document root to my development files:

[root@localhost html]# ls -l
total 4
-rwxrwxrwx. 1 root root  0 Sep 18 20:16 index.html
-rwxrwxrwx. 1 root root 17 Sep 18 20:16 index.php
lrwxrwxrwx. 1 root root 24 Sep 18 20:19 refresh-app -> /home/billy/refresh-app/

My httpd.conf has this:

<Directory "/">
    Options All
    AllowOverride None
    Order allow,deny
    Allow from all
</directory>

The target of the symbolic link has permissions which should allow apache to read anything it wants:

 [root@localhost billy]# ls -l
total 40 (Some entries were omitted because the list was too long
drwxr-xr-x. 7 billy billy 4096 Sep 18 20:03 refresh-app

I've also tried disabling SELinux by changing /etc/selinux/conf:

SELINUX=disabled

Yet no matter what I do, when someone tries to go to that link, http://localhost/refresh-app/, I get a 403 FORBIDDEN error page and this is written in the /var/log/httpd/error_log:

Symbolic link not allowed or link target not accessible

Why can't Apache access the target of the symlink?

share|improve this question
    
What user is apache running as? Can you actually read that resource as that user? –  draeath Sep 19 '11 at 16:23
    
As well, you're better off running selinux in permissive mode and then using sealert to parse the audit log - this lets you see why/how SELinux is denying it and often even gives you a resolution. –  draeath Sep 19 '11 at 16:23
    
@draeath: I have no idea how to check for that. –  Billy ONeal Sep 19 '11 at 16:43
    
@draeath: 1. This isn't a production box; I don't care if SELinux is off. 2. In any case, I am just troubleshooting at this point -- I'll probably restore it once I figure out the root cause. –  Billy ONeal Sep 19 '11 at 16:44
    
Not to worry this is a common oversight, first time i did it i was stuck for days, serverfault.com/questions/313485/… :: Its one of those errors. :D –  whoami Sep 25 '11 at 13:28
add comment

4 Answers

up vote 10 down vote accepted

Found the issue. Turns out, Apache wants access to not just the directory I'm serving, /home/billy/refresh-app/, but also every directory above that, namely /home/billy/, /home, and /. (I have no idea why... giving someone access to a subdirectory shouldn't require giving away permissions to everything above that subdirectory....)

I would guess it's looking for .htaccess or something, or perhaps *nix being strange about how it treats permissions for directory transversal.

share|improve this answer
1  
It's not strange. That's how it works. You have to have +x for the entire path you're trying to access. –  bahamat Sep 24 '11 at 20:50
2  
@bahamat: That doesn't make any sense. Why would anyone need execute privileges for files that don't get executed? (This completely discounting that one shouldn't have to give away rights to /... pretty much ever) Systems with ACLs usually have a separate directory transverse option. You'd think after 30 years since Unix was designed, and wide availability of ACL systems, that ACLs would be the standard. :sigh: –  Billy ONeal Sep 25 '11 at 1:07
2  
I believe he meant +x on directories. Try switching into the user and cd-ing to the directory w/o +x. From memory +x allows you to access but not see the directory while +r allows you to list files and +w allows you to change files in said directory –  acidzombie24 Sep 25 '11 at 20:42
    
@BillyONeal: the phrase "entire path" implies directories. –  bahamat Sep 26 '11 at 19:46
    
yep i double checked and i remembered correctly. If you only have +x on the directories and nothing else a user cant do (or see) anything to them except browse a known path to a directory were they have permissions. So essentially you probably be ok granting o+x (x to others) –  acidzombie24 Sep 28 '11 at 2:40
show 1 more comment

It appears "FollowSymLinks" is the option you need in httpd.conf. It is detailed here. Looks like you might need a rule in htdocs too...but it's the option you need.

share|improve this answer
2  
See Options All -- FollowSymLinks is already specified. –  Billy ONeal Sep 19 '11 at 16:43
add comment

This error can also be caused if you are linking to an encrypted folder.

share|improve this answer
add comment

You may also want to check if selinux is enforced or not. On RedHat/Fedora, execute this:

getenforce

If the response is 'Enforcing', you may want to execute

setenforce 0

and try the url again in your browser.

Note that I am not saying that disabling selinux is the best way to solve this problem, but it may help to identify the cause.

share|improve this answer
add comment

Your Answer

 
discard

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.