blocks|key|785451|text|检查Apache是否拥有/root、/root/site和/root/site/about的执行权限。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|785452|运行：|785453|chmod+o%2Bx+/root+/root/site+/root/site/about|code-block|syntax|javascript|785454|你可以找到一个more+secure+way+in+Elijah's+answer。|785455|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/67188746/843804^0|C|5|I|A|T|G|0|0|0|7|Y|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|13|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|14|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|15|8|@]|D|@$9|16|A|17|1|18]]|E|$]]|$1|O|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|P|$Q|$5|R|S|T|E|$U|V]]]]

Check that Apache has execute rights for <code>/root</code>, <code>/root/site</code> and <code>/root/site/about</code>.
Run:
<pre><code>chmod o+x /root /root/site /root/site/about
</code></pre>
You can find a <a href="https://stackoverflow.com/a/67188746/843804">more secure way in Elijah's answer</a>.

blocks|key|569282|text|对于任何在升级到14.04+https://askubuntu.com/questions/452042/why-is-my-apache-not-working-after-upgrading-to-ubuntu-14-04后遇到问题的用户，因为升级前更改了根目录=+/var/www+after+upgrade+=+/var/www/html|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|569283|entityMap|0|LINK|mutability|MUTABLE|url|https://askubuntu.com/questions/452042/why-is-my-apache-not-working-after-upgrading-to-ubuntu-14-04^0|E|2R|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

For anyone having trouble after upgrading to 14.04
<a href="https://askubuntu.com/questions/452042/why-is-my-apache-not-working-after-upgrading-to-ubuntu-14-04">https://askubuntu.com/questions/452042/why-is-my-apache-not-working-after-upgrading-to-ubuntu-14-04</a>
as
root changed
before upgrade = /var/www
after upgrade = /var/www/html

blocks|key|785524|text|关于这个问题，我刚刚明白为什么我的vhost会给我那个403。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|785525|我已经测试了这个问题和其他问题的所有可能性，但运气不佳。它几乎把我逼疯了。|785526|我正在通过符号链接的方式设置一个类似于Capistrano的发布部署的服务器，当我试图访问DocRoot文件夹(现在是指向当前发布文件夹的符号链接)时，它给了我403。|785527|我的vhost是：|785528|DocumentRoot+/var/www/site.com/html
<Directory+/var/www/site.com/html>
++++++++AllowOverride+All
++++++++Options+%2BFollowSymLinks
++++++++Require+all+granted
</Directory>|code-block|syntax|javascript|785529|我的主要httpd.conf文件是(默认安装Apache2.4)：|785530|DocumentRoot+"/var/www"
<Directory+"/var/www">
++++Options+-Indexes+-FollowSymLinks+-Includes
(...)|785531|事实证明，主要选项的定义优先于我的vhosts+fiel+(对我来说，这是违反直觉的)。因此我将其更改为：|785532|DocumentRoot+"/var/www"
<Directory+"/var/www">
++++Options+-Indexes+%2BFollowSymLinks+-Includes
(...)|785533|还有尤里卡！(请注意主httpd.conf文件中FollowSymLinks之前的加号。希望这能帮助其他一些迷失的灵魂。|785534|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|14|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|16|8|@]|9|@]|A|$K|L]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

Related to this question, I just figured out why my vhost was giving me that 403. 

I had tested ALL possibilities on this question and others without luck. It almost drives me mad.

I am setting up a server with releases deployment similar to Capistrano way through symlinks and when I tried to access the DocRoot folder (which is now a symlink to current release folder) it gave me the 403.

My vhost is:

<pre><code>DocumentRoot /var/www/site.com/html
&lt;Directory /var/www/site.com/html&gt;
 AllowOverride All
 Options +FollowSymLinks
 Require all granted
&lt;/Directory&gt;
</code></pre>

and my main httpd.conf file was (default Apache 2.4 install):

<pre><code>DocumentRoot "/var/www"
&lt;Directory "/var/www"&gt;
 Options -Indexes -FollowSymLinks -Includes
(...)
</code></pre>

It turns out that the main Options definition was taking precedence over my vhosts fiel (for me that is counter intuitive). So I've changed it to:

<pre><code>DocumentRoot "/var/www"
&lt;Directory "/var/www"&gt;
 Options -Indexes +FollowSymLinks -Includes
(...)
</code></pre>

and Eureka! (note the plus sign before FollowSymLinks in MAIN httpd.conf file.
Hope this help some other lost soul.

blocks|key|569370|text|正如我在我的情况下发现的那样，符号链接可能会在另一种情况下让你失败。如果将SELinux系统用作服务器，并且符号链接指向已装载NFS的文件夹(其他文件系统可能会产生类似的症状)，则httpd可能会看到错误的上下文，并拒绝提供目标文件夹的内容。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|569371|在我的例子中，/var/www/html的SELinux上下文(可以通过ls+-Z获得)是unconfined_u:object_r:httpd_sys_content_t:s0。/var/www/html中的符号链接将具有相同的上下文，但是它们的目标上下文是system_u:object_r:nfs_t:s0。|569372|解决方案是将fscontext=unconfined_u:object_r:httpd_sys_content_t:s0添加到mount选项(例如#+mount+-t+nfs+-o+v3,fscontext=unconfined_u:object_r:httpd_sys_content_t:s0+<IP+address>:/<server+path>+/<mount+point>)。rootcontext无关紧要，defcontext被NFS拒绝。我没有单独尝试过context。|569373|entityMap^0|2I|5|0|7|D|10|5|19|18|2I|D|3M|Q|0|6|1I|1R|5|21|3A|5D|B|5T|A|6I|7|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]|$9|1A|A|1B|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1C|8|@]|D|@]|E|$]]]|K|$]]

There is another way that symbolic links may fail you, as I discovered in my situation. If you have an SELinux system as the server and the symbolic links point to an NFS-mounted folder (other file systems may yield similar symptoms), <code>httpd</code> may see the wrong contexts and refuse to serve the contents of the target folders.

In my case the SELinux context of <code>/var/www/html</code> (which you can obtain with <code>ls -Z</code>) is <code>unconfined_u:object_r:httpd_sys_content_t:s0</code>. The symbolic links in <code>/var/www/html</code> will have the same context, but their target's context, being an NFS-mounted folder, are <code>system_u:object_r:nfs_t:s0</code>.

The solution is to add <code>fscontext=unconfined_u:object_r:httpd_sys_content_t:s0</code> to the <code>mount</code> options (e.g. <code># mount -t nfs -o v3,fscontext=unconfined_u:object_r:httpd_sys_content_t:s0 &lt;IP address&gt;:/&lt;server path&gt; /&lt;mount point&gt;</code>). <code>rootcontext</code> is irrelevant and <code>defcontext</code> is rejected by NFS. I did not try <code>context</code> by itself.

blocks|key|569401|text|首先禁用selinux+(vim+/etc/selinux/config)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|569402|vim+/etc/httpd/conf/httpd.conf为符号链接和目录索引编辑以下行：|569403|documentroot+/var/www/html
<directory+/var/www/html>
++++Options+Indexes+FollowSymLinks
++++AllowOverride+None
</directory>|code-block|syntax|javascript|569404|如果是.htaccess文件，则执行AllowOverride+all|569405|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

First disable selinux (vim /etc/selinux/config)

vim /etc/httpd/conf/httpd.conf edit following lines for symlinks and directory indexing:

<pre><code>documentroot /var/www/html
&lt;directory /var/www/html&gt;
 Options Indexes FollowSymLinks
 AllowOverride None
&lt;/directory&gt;
</code></pre>

If .htaccess file then AllowOverride all

blocks|key|785620|text|除了像其他答案指出的那样更改权限外，我还必须重新启动apache才能使其生效：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|785621|sudo+service+apache2+restart|code-block|syntax|javascript|785622|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

In addition to changing the permissions as the other answers have indicated, I had to restart apache for it to take effect:

<pre><code>sudo service apache2 restart
</code></pre>

blocks|key|785671|text|另一个微妙的陷阱是，如果您需要AllowOverride+All|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|785672|在fs树的某处，一个旧的.htaccess具有|785673|Options+Indexes|785674|而不是|785675|Options+%2BIndexes|785676|这就是在服务器配置中随意禁用FollowSymLinks设置所需的全部内容，并在此处导致了神秘的403。|785677|entityMap^0|F|H|0|C|9|0|0|F|0|0|0|G|0|E|E|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|10|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|11|8|@$9|12|A|13|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@]|E|$]]|$1|P|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|Q|$]]

Yet another subtle pitfall, in case you need <code>AllowOverride All</code>:

Somewhere deep in the fs tree, an old <code>.htaccess</code> having

&nbsp;&nbsp;&nbsp;&nbsp;<code>Options Indexes</code>

instead of

&nbsp;&nbsp;&nbsp;&nbsp;<code>Options +Indexes</code>

was all it took to nonchalantly disable the <code>FollowSymLinks</code> set in the server config, and cause a mysterious 403 here.

blocks|key|569627|text|在启用FollowSymLinks选项的情况下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|569628|$+rg+"FollowSymLinks"+/etc/httpd/
/etc/httpd/conf/httpd.conf
269:++++Options+Indexes+FollowSymLinks|code-block|syntax|javascript|569629|您需要symlink中的所有目录都可以由httpd使用的用户执行。|569630|因此，对于这个通用用例：|569631|cd+/path/to/your/web
sudo+ln+-s+$PWD+/srv/http/|569632|您可以使用namei检查所有者和权限|offset|length|569633|$+namei+-m+/srv/http/web
f:+/srv/http/web
+drwxr-xr-x+/
+drwxr-xr-x+srv
+drwxr-xr-x+http
+lrwxrwxrwx+web+->+/path/to/your/web
+++drwxr-xr-x+/
+++drwxr-xr-x+path
+++drwx------+to
+++drwxr-xr-x+your
+++drwxr-xr-x+web|569634|在我的例子中，to目录只对我的用户可执行：|style|CODE|569635|启用其他人的执行解算它：|569636|chmod+o%2Bx+/path/to|569637|看到不可执行的目录可能不同，或者你需要影响组而不是其他人，这取决于你的情况。|569638|entityMap|0|LINK|mutability|MUTABLE|url|https://linux.die.net/man/1/namei^0|0|0|0|0|0|5|5|0|0|0|7|2|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1B|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1C|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1D|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|1E|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|1F|8|@]|9|@$O|1G|P|1H|1|1I]]|A|$]]|$1|Q|3|R|5|D|7|1J|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|1K|8|@$O|1L|P|1M|U|V]]|9|@]|A|$]]|$1|W|3|X|5|6|7|1N|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|D|7|1O|8|@]|9|@]|A|$E|F]]|$1|10|3|11|5|6|7|1P|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]]|13|$14|$5|15|16|17|A|$18|19]]]]

With the option FollowSymLinks enabled:
<pre><code>$ rg &quot;FollowSymLinks&quot; /etc/httpd/
/etc/httpd/conf/httpd.conf
269: Options Indexes FollowSymLinks
</code></pre>
you need all the directories in symlink to be executable by the user httpd is using.
so for this general use case:
<pre><code>cd /path/to/your/web
sudo ln -s $PWD /srv/http/
</code></pre>
You can check owner an permissions with <a href="https://linux.die.net/man/1/namei" rel="nofollow noreferrer">namei</a>:
<pre><code>$ namei -m /srv/http/web
f: /srv/http/web
 drwxr-xr-x /
 drwxr-xr-x srv
 drwxr-xr-x http
 lrwxrwxrwx web -&gt; /path/to/your/web
 drwxr-xr-x /
 drwxr-xr-x path
 drwx------ to
 drwxr-xr-x your
 drwxr-xr-x web
</code></pre>
In my case <code>to</code> directory was only executable for my user:
Enable execution by others solve it:
<pre><code>chmod o+x /path/to
</code></pre>
See the non executable directory could be different, or you need to affect groups instead others, that depends on your case.

blocks|key|785789|text|正如在Arch+wiki上的this讨论中所建议的，为另一组设置完整路径的默认方法是使用：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|785790|chmod+o%2Bx+/root+/root/site+/root/site/about|code-block|syntax|javascript|785791|不是最安全的方式，因为任何有权访问服务器的用户都能够访问和执行公开路径上的文件。|785792|最好是使用ACL权限为特定用户设置权限。在Apache+HTTP服务器的情况下，该用户将是"http"，并且可以通过执行以下操作来设置权限(在arch中，您需要安装acl包)：|style|CODE|785793|setfacl+-m+"u:http:--x"+/path/to/directory"|785794|您必须递归地设置它(首先设置为/path，然后设置为/path/，依此类推)。|785795|与投票最多的解决方案相比，只有特定用户可以访问此目录，因此安全性得到了提高。|785796|额外提示:如果路径挂载在zfs池中，则需要在zpool配置中添加acltype选项。这可以通过以下方式完成：|785797|zfs+set+acltype=posixacl+your_zpool|785798|然后，通过重新启动计算机，将使用正确的配置再次挂载该卷，并且上面的代码将正常工作。|785799|entityMap|0|LINK|mutability|MUTABLE|url|https://wiki.archlinux.org/index.php/Access_Control_Lists#Granting_execution_permissions_for_private_files_to_a_web_server^0|E|4|0|0|0|0|2A|3|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@$A|19|B|1A|1|1B]]|C|$]]|$1|D|3|E|5|F|7|1C|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|1D|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|1E|8|@$A|1F|B|1G|M|N]]|9|@]|C|$]]|$1|O|3|P|5|F|7|1H|8|@]|9|@]|C|$G|H]]|$1|Q|3|R|5|6|7|1I|8|@]|9|@]|C|$]]|$1|S|3|T|5|6|7|1J|8|@]|9|@]|C|$]]|$1|U|3|V|5|6|7|1K|8|@]|9|@]|C|$]]|$1|W|3|X|5|F|7|1L|8|@]|9|@]|C|$G|H]]|$1|Y|3|Z|5|6|7|1M|8|@]|9|@]|C|$]]|$1|10|3|-4|5|6|7|1N|8|@]|9|@]|C|$]]]|11|$12|$5|13|14|15|C|$16|17]]]]

As recommended on <a href="https://wiki.archlinux.org/index.php/Access_Control_Lists#Granting_execution_permissions_for_private_files_to_a_web_server" rel="nofollow noreferrer">this</a> discussion on the Arch wiki, the default approach of setting the whole path for the other group using:
<pre><code>chmod o+x /root /root/site /root/site/about
</code></pre>
is not the most secure way, since any user with access to the server will be able to access and execute files on the path exposed.
Preferably, you should set permissions to a particular user using ACL permissions.
In the case of the Apache HTTP server, that user would be &quot;http&quot;, and permissions could be set by doing (in arch, you will need the <code>acl</code> package installed):
<pre><code>setfacl -m &quot;u:http:--x&quot; /path/to/directory&quot;
</code></pre>
You will have to set this recursively (first to /path, then /path/to, etc).
Compared to the most voted solution, only a particular user will be able to access this directory, so security is increased.
Bonus tip: if the path is mounted on a zfs pool, you will need to add the option acltype in your zpool configuration. This can be done with:
<pre><code>zfs set acltype=posixacl your_zpool
</code></pre>
Then, by restarting the machine, the volume will be mounted again with the correct configuration, and the code above will work.

I'm having some trouble setting up Apache on Ubuntu. I've been following <a href="http://library.linode.com/lamp-guides/ubuntu-11.04-natty">this guide</a>.

<pre><code># /usr/sbin/apache2 -v
Server version: Apache/2.2.17 (Ubuntu)
Server built: Feb 22 2011 18:33:02
</code></pre>

My public directory, /var/www, can successfully serve up and execute PHP pages that are placed in it. However, I want to create a symlink in /var/www that points to a directory in my home folder and serve pages there. 

<pre><code>[root /var/www]# ll
total 36
drwxr-xr-x 3 root root 4096 2011-09-11 14:22 .
drwxr-xr-x 14 root root 4096 2011-06-04 22:49 ..
lrwxrwxrwx 1 root root 16 2011-09-11 13:21 about -&gt; /root/site/about
</code></pre>

When I try to access /about on browser, I get 

<pre><code>Forbidden

You don't have permission to access /about on this server.
</code></pre>

As far as I know, I gave sufficient privileges to the files I want to serve:

<pre><code>[root ~/site/about]# ll
total 24
drwxr-xr-x 5 root root 4096 2011-09-11 13:20 .
drwxr--r-- 3 root root 4096 2011-09-11 13:19 ..
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 contact
-rwxr-xr-x 1 root root 1090 2011-09-11 13:19 index.php
drwxr-xr-x 2 root root 4096 2011-09-11 13:20 me
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 resume
</code></pre>

I'm aware of the FollowSymLinks option, and I believe it's set in my /etc/apache2/sites-enabled/000-default file:

<pre><code>DocumentRoot /var/www
&lt;Directory /&gt;
 Options FollowSymLinks
 AllowOverride None
&lt;/Directory&gt;
&lt;Directory /var/www/&gt;
 Options FollowSymLinks Indexes MultiViews
 AllowOverride None
 Order allow,deny
 allow from all
&lt;/Directory&gt;
</code></pre>

Any idea what I could be missing?

Apache won't follow symlinks (403 Forbidden)

文件系统

服务器

Ubuntu

我在Ubuntu上安装Apache时遇到了一些问题。我一直在跟踪。# /usr/sbin/apache2 -vServer version: Apache/2.2.17 (Ubuntu)Server built:   Feb 22 2011 18:33:02我的公共目录/var/www可以成功地提供并执行放置在其中的P...

问Apache不会遵循符号链接(403禁止)
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Apache不会遵循符号链接(403禁止)EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Apache不会遵循符号链接(403禁止)
EN