âSymbolic link not allowed or link target not accessibleâ / Apache on CentOS 6

Clash Royale CLAN TAG#URR8PPP
up vote
28
down vote
favorite
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?
centos permissions apache-httpd
 |Â
show 1 more comment
up vote
28
down vote
favorite
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?
centos permissions apache-httpd
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
 |Â
show 1 more comment
up vote
28
down vote
favorite
up vote
28
down vote
favorite
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?
centos permissions apache-httpd
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?
centos permissions apache-httpd
edited May 13 '16 at 2:46
Jeff Schaller
31.2k846105
31.2k846105
asked Sep 19 '11 at 1:43
Billy ONeal
6901612
6901612
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
 |Â
show 1 more comment
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
What user is apache running as? Can you actually read that resource as that user?
â draeath
Sep 19 '11 at 16:23
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
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: 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
@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
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
 |Â
show 1 more comment
9 Answers
9
active
oldest
votes
up vote
41
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.
13
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
4
@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
10
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
â user4069
Sep 25 '11 at 20:42
1
@BillyONeal: the phrase "entire path" implies directories.
â bahamat
Sep 26 '11 at 19:46
5
This is correct behavior in unix. You need execute privileges (+x for g or o) on parent directories that you're trying to change into sub-directories underneath them.
â slmâ¦
Dec 28 '12 at 1:14
 |Â
show 3 more comments
up vote
8
down vote
I had a similar problem where I had the following configuration which used to work with Ubuntu 10, but stopped working with Ubuntu 14 (Apache 2.4):
<Directory /var/www/vhosts/example.com/httpdocs>
Options +FollowSymLinks
</Directory>
Switching to this sorted the problem (even though the web server user wasn't able to directly access the symlink)
<Directory /var/www/vhosts/example.com/httpdocs>
Options +ExecCGI +FollowSymlinks -SymLinksIfOwnerMatch
</Directory>
From what I can tell its just the -SymLinksIfOwnerMatch setting and has something to do with changes in Apache 2.4 but I haven't tried researching the exact cause.
I also thought it could be down to openbase_dir restrictions in PHP but it wasn't that.
add a comment |Â
up vote
6
down vote
This error can also be caused if you are linking to an encrypted folder.
add a comment |Â
up vote
3
down vote
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.
3
SeeOptions All--FollowSymLinksis already specified.
â Billy ONeal
Sep 19 '11 at 16:43
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
Options +FollowSymLinks
Create a .htaccess file with this did the trick for me (put it in a dir before the symlink).
add a comment |Â
up vote
0
down vote
that what solve my problem after allow all permission and allow followsymlink
"
In the case of FollowSymLinks specifically it MUST be inside a Directory structure when within a .conf file. From the Apache current manual
The FollowSymLinks and SymLinksIfOwnerMatch Options work only in
sections or .htaccess files.
answer from here
add a comment |Â
up vote
0
down vote
My solution was to create a shared folder for all repositories named /home/repo.
Then symlink from my own home like: ln -s /home/repo ~/Code
so ~/Code/www.xxxx.com/public
points to /home/repo/www.xxxx.com/public
and also a link into apache web root /var/www/html
points to /home/repo/www.xxxx.com/public
Found it here:
https://github.com/alghanmi/ubuntu-desktop_setup/wiki/Git-Local-Repository-Setup-Guide
With some symlink+user groups acrobacy you can have multiple users/versions deployed.
add a comment |Â
up vote
-1
down vote
You might also adjust your SELinux settings, and setenforce may not be on your path. So try this:
sudo /usr/sbin/setenforce 0
and to make this persist between reboots
sudo vi /etc/sysconfig/selinux
add a comment |Â
9 Answers
9
active
oldest
votes
9 Answers
9
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
41
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.
13
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
4
@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
10
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
â user4069
Sep 25 '11 at 20:42
1
@BillyONeal: the phrase "entire path" implies directories.
â bahamat
Sep 26 '11 at 19:46
5
This is correct behavior in unix. You need execute privileges (+x for g or o) on parent directories that you're trying to change into sub-directories underneath them.
â slmâ¦
Dec 28 '12 at 1:14
 |Â
show 3 more comments
up vote
41
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.
13
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
4
@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
10
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
â user4069
Sep 25 '11 at 20:42
1
@BillyONeal: the phrase "entire path" implies directories.
â bahamat
Sep 26 '11 at 19:46
5
This is correct behavior in unix. You need execute privileges (+x for g or o) on parent directories that you're trying to change into sub-directories underneath them.
â slmâ¦
Dec 28 '12 at 1:14
 |Â
show 3 more comments
up vote
41
down vote
accepted
up vote
41
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.
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.
answered Sep 24 '11 at 5:07
Billy ONeal
6901612
6901612
13
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
4
@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
10
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
â user4069
Sep 25 '11 at 20:42
1
@BillyONeal: the phrase "entire path" implies directories.
â bahamat
Sep 26 '11 at 19:46
5
This is correct behavior in unix. You need execute privileges (+x for g or o) on parent directories that you're trying to change into sub-directories underneath them.
â slmâ¦
Dec 28 '12 at 1:14
 |Â
show 3 more comments
13
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
4
@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
10
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
â user4069
Sep 25 '11 at 20:42
1
@BillyONeal: the phrase "entire path" implies directories.
â bahamat
Sep 26 '11 at 19:46
5
This is correct behavior in unix. You need execute privileges (+x for g or o) on parent directories that you're trying to change into sub-directories underneath them.
â slmâ¦
Dec 28 '12 at 1:14
13
13
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
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
4
4
@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
@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
10
10
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
â user4069
Sep 25 '11 at 20:42
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
â user4069
Sep 25 '11 at 20:42
1
1
@BillyONeal: the phrase "entire path" implies directories.
â bahamat
Sep 26 '11 at 19:46
@BillyONeal: the phrase "entire path" implies directories.
â bahamat
Sep 26 '11 at 19:46
5
5
This is correct behavior in unix. You need execute privileges (+x for g or o) on parent directories that you're trying to change into sub-directories underneath them.
â slmâ¦
Dec 28 '12 at 1:14
This is correct behavior in unix. You need execute privileges (+x for g or o) on parent directories that you're trying to change into sub-directories underneath them.
â slmâ¦
Dec 28 '12 at 1:14
 |Â
show 3 more comments
up vote
8
down vote
I had a similar problem where I had the following configuration which used to work with Ubuntu 10, but stopped working with Ubuntu 14 (Apache 2.4):
<Directory /var/www/vhosts/example.com/httpdocs>
Options +FollowSymLinks
</Directory>
Switching to this sorted the problem (even though the web server user wasn't able to directly access the symlink)
<Directory /var/www/vhosts/example.com/httpdocs>
Options +ExecCGI +FollowSymlinks -SymLinksIfOwnerMatch
</Directory>
From what I can tell its just the -SymLinksIfOwnerMatch setting and has something to do with changes in Apache 2.4 but I haven't tried researching the exact cause.
I also thought it could be down to openbase_dir restrictions in PHP but it wasn't that.
add a comment |Â
up vote
8
down vote
I had a similar problem where I had the following configuration which used to work with Ubuntu 10, but stopped working with Ubuntu 14 (Apache 2.4):
<Directory /var/www/vhosts/example.com/httpdocs>
Options +FollowSymLinks
</Directory>
Switching to this sorted the problem (even though the web server user wasn't able to directly access the symlink)
<Directory /var/www/vhosts/example.com/httpdocs>
Options +ExecCGI +FollowSymlinks -SymLinksIfOwnerMatch
</Directory>
From what I can tell its just the -SymLinksIfOwnerMatch setting and has something to do with changes in Apache 2.4 but I haven't tried researching the exact cause.
I also thought it could be down to openbase_dir restrictions in PHP but it wasn't that.
add a comment |Â
up vote
8
down vote
up vote
8
down vote
I had a similar problem where I had the following configuration which used to work with Ubuntu 10, but stopped working with Ubuntu 14 (Apache 2.4):
<Directory /var/www/vhosts/example.com/httpdocs>
Options +FollowSymLinks
</Directory>
Switching to this sorted the problem (even though the web server user wasn't able to directly access the symlink)
<Directory /var/www/vhosts/example.com/httpdocs>
Options +ExecCGI +FollowSymlinks -SymLinksIfOwnerMatch
</Directory>
From what I can tell its just the -SymLinksIfOwnerMatch setting and has something to do with changes in Apache 2.4 but I haven't tried researching the exact cause.
I also thought it could be down to openbase_dir restrictions in PHP but it wasn't that.
I had a similar problem where I had the following configuration which used to work with Ubuntu 10, but stopped working with Ubuntu 14 (Apache 2.4):
<Directory /var/www/vhosts/example.com/httpdocs>
Options +FollowSymLinks
</Directory>
Switching to this sorted the problem (even though the web server user wasn't able to directly access the symlink)
<Directory /var/www/vhosts/example.com/httpdocs>
Options +ExecCGI +FollowSymlinks -SymLinksIfOwnerMatch
</Directory>
From what I can tell its just the -SymLinksIfOwnerMatch setting and has something to do with changes in Apache 2.4 but I haven't tried researching the exact cause.
I also thought it could be down to openbase_dir restrictions in PHP but it wasn't that.
answered May 8 '15 at 18:10
icc97
18514
18514
add a comment |Â
add a comment |Â
up vote
6
down vote
This error can also be caused if you are linking to an encrypted folder.
add a comment |Â
up vote
6
down vote
This error can also be caused if you are linking to an encrypted folder.
add a comment |Â
up vote
6
down vote
up vote
6
down vote
This error can also be caused if you are linking to an encrypted folder.
This error can also be caused if you are linking to an encrypted folder.
answered Dec 28 '12 at 0:47
cherrysoft
48646
48646
add a comment |Â
add a comment |Â
up vote
3
down vote
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.
3
SeeOptions All--FollowSymLinksis already specified.
â Billy ONeal
Sep 19 '11 at 16:43
add a comment |Â
up vote
3
down vote
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.
3
SeeOptions All--FollowSymLinksis already specified.
â Billy ONeal
Sep 19 '11 at 16:43
add a comment |Â
up vote
3
down vote
up vote
3
down vote
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.
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.
answered Sep 19 '11 at 2:12
RobotHumans
1,299814
1,299814
3
SeeOptions All--FollowSymLinksis already specified.
â Billy ONeal
Sep 19 '11 at 16:43
add a comment |Â
3
SeeOptions All--FollowSymLinksis already specified.
â Billy ONeal
Sep 19 '11 at 16:43
3
3
See
Options All -- FollowSymLinks is already specified.â Billy ONeal
Sep 19 '11 at 16:43
See
Options All -- FollowSymLinks is already specified.â Billy ONeal
Sep 19 '11 at 16:43
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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.
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.
answered Feb 19 '14 at 10:45
botkop
1603
1603
add a comment |Â
add a comment |Â
up vote
1
down vote
Options +FollowSymLinks
Create a .htaccess file with this did the trick for me (put it in a dir before the symlink).
add a comment |Â
up vote
1
down vote
Options +FollowSymLinks
Create a .htaccess file with this did the trick for me (put it in a dir before the symlink).
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Options +FollowSymLinks
Create a .htaccess file with this did the trick for me (put it in a dir before the symlink).
Options +FollowSymLinks
Create a .htaccess file with this did the trick for me (put it in a dir before the symlink).
answered May 24 '15 at 22:00
Codebeat
1112
1112
add a comment |Â
add a comment |Â
up vote
0
down vote
that what solve my problem after allow all permission and allow followsymlink
"
In the case of FollowSymLinks specifically it MUST be inside a Directory structure when within a .conf file. From the Apache current manual
The FollowSymLinks and SymLinksIfOwnerMatch Options work only in
sections or .htaccess files.
answer from here
add a comment |Â
up vote
0
down vote
that what solve my problem after allow all permission and allow followsymlink
"
In the case of FollowSymLinks specifically it MUST be inside a Directory structure when within a .conf file. From the Apache current manual
The FollowSymLinks and SymLinksIfOwnerMatch Options work only in
sections or .htaccess files.
answer from here
add a comment |Â
up vote
0
down vote
up vote
0
down vote
that what solve my problem after allow all permission and allow followsymlink
"
In the case of FollowSymLinks specifically it MUST be inside a Directory structure when within a .conf file. From the Apache current manual
The FollowSymLinks and SymLinksIfOwnerMatch Options work only in
sections or .htaccess files.
answer from here
that what solve my problem after allow all permission and allow followsymlink
"
In the case of FollowSymLinks specifically it MUST be inside a Directory structure when within a .conf file. From the Apache current manual
The FollowSymLinks and SymLinksIfOwnerMatch Options work only in
sections or .htaccess files.
answer from here
edited May 23 '17 at 10:49
Romeo Ninov
4,35811625
4,35811625
answered May 23 '17 at 9:44
yoni333
11
11
add a comment |Â
add a comment |Â
up vote
0
down vote
My solution was to create a shared folder for all repositories named /home/repo.
Then symlink from my own home like: ln -s /home/repo ~/Code
so ~/Code/www.xxxx.com/public
points to /home/repo/www.xxxx.com/public
and also a link into apache web root /var/www/html
points to /home/repo/www.xxxx.com/public
Found it here:
https://github.com/alghanmi/ubuntu-desktop_setup/wiki/Git-Local-Repository-Setup-Guide
With some symlink+user groups acrobacy you can have multiple users/versions deployed.
add a comment |Â
up vote
0
down vote
My solution was to create a shared folder for all repositories named /home/repo.
Then symlink from my own home like: ln -s /home/repo ~/Code
so ~/Code/www.xxxx.com/public
points to /home/repo/www.xxxx.com/public
and also a link into apache web root /var/www/html
points to /home/repo/www.xxxx.com/public
Found it here:
https://github.com/alghanmi/ubuntu-desktop_setup/wiki/Git-Local-Repository-Setup-Guide
With some symlink+user groups acrobacy you can have multiple users/versions deployed.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
My solution was to create a shared folder for all repositories named /home/repo.
Then symlink from my own home like: ln -s /home/repo ~/Code
so ~/Code/www.xxxx.com/public
points to /home/repo/www.xxxx.com/public
and also a link into apache web root /var/www/html
points to /home/repo/www.xxxx.com/public
Found it here:
https://github.com/alghanmi/ubuntu-desktop_setup/wiki/Git-Local-Repository-Setup-Guide
With some symlink+user groups acrobacy you can have multiple users/versions deployed.
My solution was to create a shared folder for all repositories named /home/repo.
Then symlink from my own home like: ln -s /home/repo ~/Code
so ~/Code/www.xxxx.com/public
points to /home/repo/www.xxxx.com/public
and also a link into apache web root /var/www/html
points to /home/repo/www.xxxx.com/public
Found it here:
https://github.com/alghanmi/ubuntu-desktop_setup/wiki/Git-Local-Repository-Setup-Guide
With some symlink+user groups acrobacy you can have multiple users/versions deployed.
edited Oct 31 '17 at 23:43
Eduardo Baitello
436217
436217
answered Oct 31 '17 at 22:23
alo Malbarez
24115
24115
add a comment |Â
add a comment |Â
up vote
-1
down vote
You might also adjust your SELinux settings, and setenforce may not be on your path. So try this:
sudo /usr/sbin/setenforce 0
and to make this persist between reboots
sudo vi /etc/sysconfig/selinux
add a comment |Â
up vote
-1
down vote
You might also adjust your SELinux settings, and setenforce may not be on your path. So try this:
sudo /usr/sbin/setenforce 0
and to make this persist between reboots
sudo vi /etc/sysconfig/selinux
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
You might also adjust your SELinux settings, and setenforce may not be on your path. So try this:
sudo /usr/sbin/setenforce 0
and to make this persist between reboots
sudo vi /etc/sysconfig/selinux
You might also adjust your SELinux settings, and setenforce may not be on your path. So try this:
sudo /usr/sbin/setenforce 0
and to make this persist between reboots
sudo vi /etc/sysconfig/selinux
answered Oct 3 '14 at 17:44
Rami Jaamour
1
1
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f20993%2fsymbolic-link-not-allowed-or-link-target-not-accessible-apache-on-centos-6%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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