Apache: доступ запрещен, потому что отсутствуют разрешения на поиск


75

Я знаю, что этот вопрос часто задают, но решения, которые я видел, не сработали для меня.

У меня включен только один виртуальный хост, и я пытаюсь разрешить доступ к папке, которая не находится в корне документа

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html

Alias /movies /home/username/Videos/Movies

<Directory /home/username/Videos/Movies/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Я установил /etc/apache2/envvarsследующее

export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=public

Я удостоверился, что / home / username / Videos / и его подпапки принадлежат username:public, установил разрешения на 777 (после 775 не работал) и убедился, что пользователь www-dataпринадлежит группе public.

Теперь, когда я http://localhost/moviesсмотрю, я получаю

[Mon Apr 21 11:28:14.971844 2014] [core:error] [pid 1385:tid 140067725104896] (13)Permission denied: [client 127.0.0.1:46603] AH00035: access to /movies/ denied (filesystem path '/home/username/Videos') because search permissions are missing on a component of the path

Но когда я /etc/apache2/envvarsзапускаю Apache под usernameмоим собственным именем, все работает нормально. Проблема связана с разрешением, но я не понимаю, как в моем случае; особенно когда я устанавливаю разрешения для 777. Есть идеи?

PS Версия Ubuntu 14.04, Apache 2.4.7, я не редактировал другие файлы конфигурации.



Я сделал все, что они предложили там, как я написал, и это не помогает
Yotam

Есть ли шанс, что вы установили свой /homeс включенным ACL? (в конце битов разрешений есть знак "+", если это так (проверьте с помощью ls -l))
Полоссон,

Нет, я этого не делал. Сейчас я запускаю Apache под своим пользователем, поэтому он работает, но я бы хотел запустить его под другим пользователем из соображений безопасности.
Йотам

Я использую Linux впервые. Я скачал версию Ubuntu 14.04 LTE. Я сталкиваюсь с той же проблемой. Может кто-нибудь помочь, пожалуйста?
Имдад

Ответы:


95

Сделайте chmod +xна своем пользователе dir и перезапустите apache. 755 разрешений должны работать. У меня были проблемы с 644 .


6
Действительно, и для двойной проверки прав доступа к файлам и каталогам, если они доступны, вы можете использовать namei -m /home/youruser/public_html/yourfile.extили попробовать people.apache.org/~igalic/hacks/parsepath
Junior M

2
чтобы уточнить, любой каталог, который вы хотите прочитать в Apache, должен быть доступен для чтения для пользователя Apache. Скорее всего, ваша домашняя папка пользователя не принадлежит вашему пользователю и группе, поэтому вам нужно установить 755 разрешений /home/usernameдля доступа к ней с помощью apace.
Ruuter

У меня была эта проблема на OSX Mac OS High Sierra, и это решение работало для меня. Даже не пришлось перезагружать Apache.
прошло

После нескольких часов поиска выясняется, что права доступа должны быть правильными и для родительских каталогов DocumentRoot. Большое спасибо . Кстати, для этого не нужно перезапускать Apache
бухгалтер م

27

Если в случае с selinux возникает проблема, а не просто отключить ее, эта страница и эта страница дают команду для предоставления доступа:

chcon -R -t httpd_sys_content_t ~/public_html/

1
Я был уверен, что это была моя проблема. Черт CentOS! Спасибо за команду, работает отлично.
Balmipour

2
спасибо, просто пришлось заменить ~/public_html/часть корневым каталогом контента, который я пытался обслуживать.
trpt4him

chcon -R -t httpd_sys_content_t /var/www/html/phpmyadmin/(в моей ситуации)
cssyphus

Обнаруженный selinux не может обрабатывать простые домашние каталоги, и требуется только одна из этих функций, а другая - необязательная. Спасибо за напоминание об исправлении - после обязательного периода повторного тестирования с каждым новым выпуском и разочарованием я обычно просто исправляю это в кикстарте. Теперь для systemd.
user2066657

17

Возможно, вы включили selinux. Пытаться

getenforce

Если он показывает «Принудительный», попробуйте

setenforce 0

и попробуйте, если это решит вашу проблему.


4
Не просто отключите SELinux как исправление. Исправьте проблемы SELinux, переназначив порты или установив логические значения.
Сирида

1
Этот ответ помогает определить, что проблема связана с SELinux. Но отключать его не рекомендуется.
Раджкумар Р

15

Я столкнулся с той же проблемой, после нескольких часов попыток, я нашел решение, которое точно решает проблему:

https://wiki.apache.org/httpd/13PermissionDenied

По сути, серверу Apache требуются не только разрешения на чтение всех файлов, которые он обслуживает, но и разрешение на выполнение всех каталогов на пути вашего виртуального хоста.

Утилиту namei можно использовать для поиска проблем с разрешениями, перечислив разрешения для каждого компонента пути:

namei --modes /usr/local/apache2/htdocs/foo/bar.html

В моем случае каталог в моем пути имеет разрешение 700, это вызывает проблему. После замены на 701 проблема была решена.


1
Ссылка здесь полезна, потому что объясняет проблему: один из узлов в пути к каталогу не имеет разрешений на поиск. Используйте команду «namei», чтобы найти это, а затем «chmod» на 755.
user3751385

Это объясняет как реальную причину, так и решение. спасибо
Emdadul Sawon

1

Я столкнулся с этой проблемой, когда пытался запустить apache в док-контейнере на хосте Ubuntu 16.04, который использовал ядро ​​4.4 вместо 4.10.

После того, как я выполнил эту команду на хосте и повторно развернул ее, я был в порядке:

sudo apt-get install --install-recommends linux-generic-hwe-16.04 

Я столкнулся с этой проблемой, но со странным эффектом, который я могу chmodили chownвнутри контейнера, и он на некоторое время подавляет ошибки Apache 403, только чтобы вернуться через некоторое время. Насколько я могу судить, причиной этого может быть не перезапуск контейнера или другие существенные изменения. Поскольку я действительно работаю 16.04, я попытался установить этот двоичный файл, и мои 403-е пока держатся в стороне. Я буду следить за этим, и спасибо!
Половник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.