Как исправить 403 в Mac OS X встроенного Apache?

Я пытаюсь установить локальную среду на моем новом MacBook Air 13 ": встроенный Apache с моими собственными DocumentRoot, PHP и MySQL. Я обычно обновляюсь, /etc/hostsчтобы просто запускать свои локальные веб-сайты с довольно постоянной local/exampleссылкой. Для справок я обычно чек:

• Как превратить Mac OS X Lion в веб-сервер?
• Включение Apache в Mac OS X Mountaion Lion
• Разрешения Apache

На этот раз я просто получаю 403 Запретной ошибку каждый раз , когда я ударил 127.0.0.1, localhostили local. Сначала я увидел через терминал, что Apache и PHP работают (хотя я не могу просматривать страницы PHP); затем я обновил все разрешения в соответствии с разрешениями Apache ; теперь я просто в отчаянии. Вот соответствующие конфиги Apache:

• /etc/hosts( просмотр файла - добавлена ​​одна строка)
• /etc/apache2/httpd.conf( просмотреть файл - обновил DocumentRoot)
• /etc/apache2/users/joao.conf( просмотреть файл - создал этот файл)
• /etc/apache2/extra/httpd-vhosts.conf( просмотреть файл - обновлено VirtualHost)

Похоже, что Apache почему-то отказывает мне в доступе к моему DocumentRoot(что, кстати, есть ~/Sites). Поскольку ~/Sitesна самом деле это символическая ссылка, я затем попытался обновить DocumentRootс помощью следующих путей (все указывают на один и тот же каталог):

• ~/Sites
• /Users/joao/Sites
• /Users/joao/Dropbox/Workflow/Sites( оригинальный каталог)

Все еще выбрасываю 403 . Любые идеи, как это исправить / отладить?

Быстрое обновление - вот как /var/log/apache2/joao.pt-error_logвыглядит мой :

[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to / denied
[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:45 2013] [error] [client 127.0.0.1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:47 2013] [error] [client ::1] (13)Permission denied: access to / denied
[Sun Jul 07 12:50:47 2013] [error] [client ::1] (13)Permission denied: access to / denied
[Sun Jul 07 12:50:48 2013] [error] [client ::1] (13)Permission denied: access to /favicon.ico denied
[Sun Jul 07 12:50:48 2013] [error] [client ::1] (13)Permission denied: access to /favicon.ico denied

У меня есть псевдоним, указанный на сервере OSX, указывающий на каталог пользователя. Я потратил много времени на chmodding и связывался с пользователем _www, рекурсивно добавляя права на исполняемые файлы, удаляя macports и всякие другие вещи, пытаясь заставить это работать. Не знаю, почему это не сработало.

В конце концов, я просто установил флажок «Общая папка» в Finder для этой папки, и он работал , на указанном домене, с активным php, так, как я этого хотел. : / ... так что было легко.

Я обновляю до macOSS Sierra , Версия 10.12

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

1) Пожалуйста, проверьте файл " /private/etc/apache2/extra/httpd-userdir.conf ". + Изменить

#Include /private/etc/apache2/users/*.conf

в

Include /private/etc/apache2/users/*.conf

2) ** И отредактируйте свой " /etc/apache2/httpd.conf"

менять

Options FollowSymLinks Multiviews

в

Options FollowSymLinks Multiviews Indexes

наконец, ваш корень документа будет выглядеть следующим образом,

DocumentRoot "/Library/WebServer/Documents"
<Directory "/Library/WebServer/Documents">
Options FollowSymLinks Multiviews Indexes
MultiviewsMatch Any
AllowOverride All
Require all granted

3) Перезапустите apache

sudo apachectl restart

Тем не менее, вы столкнулись с проблемой, пожалуйста, проверьте, как настроить Apache в macOS Sierra 10.12

Обычно я исправляю это, настраивая пользователя Apache для себя в локальной среде и на машинах, где единственным пользователем, использующим Apache, является я. В /private/etc/apache2/httpd.conf, установите Userваше имя пользователя из _www, например:

User _www

->

User joao

А затем перезапустите Apache:

$ sudo apachectl restart

Дополнительные шаги:

1. Если у вас есть активные сеансы, они будут выдавать ошибки разрешения, так как они все еще принадлежат _www. Собственные им:

   $ sudo chown joao: /var/tmp/sess_*
   

Последствия:

После этого Apache (и PHP и др.) Будут работать от вашего имени и получат разрешение на чтение / запись для всех файлов, для которых у вас есть разрешение на чтение / запись. Но так как это всего лишь локальная среда разработки, это не должно быть проблемой, если у вас нет правил, чтобы блокировать Apache в брандмауэре и позволить сомнительным файлам, таким как проводники файлов, оболочки, скрипты, которые могут содержать уязвимости, работать под Apache; в этом случае любой, в том числе ваш общедоступный Wi-Fi-сосед в кафе, может войти http://<your IP>и сделать все, что позволят ему эти сценарии.

Фактически, вы должны предотвратить это независимо от того, какие скрипты вы запускаете, или даже если вы не настраиваете пользователя Apache для себя, поскольку вы, вероятно, не хотите, чтобы случайные посторонние лица могли видеть содержимое вашего localhost.

Предупреждение:

1. Заставьте Apache слушать только localhost. Опять же, в httpd.conf:

   Listen 80
   

   ->

   Listen 127.0.0.1:80
   

   И перезапустите Apache снова:

   $ sudo apachectl restart
   

2. Отключите Apache в брандмауэре приложения (обратите внимание, что вы, возможно, уже отключили его, если щелкнули, Denyесли / когда его спросили во время первого запуска Apache):

   1. Открыть System Preferences» Security & Privacy» Firewall.
   2. Нажмите на значок замка слева внизу и введите свой пароль, если это необходимо.
   3. Включите брандмауэр, если он отключен.
   4. Нажмите Firewall Options.
   5. Нажмите на +кнопку.
   6. Нажмите cmd ⌘+ ⇧ shift+, Gвойдите /usr/sbin/httpdи нажмите Add(Если httpdтам нет, вы можете найти его в терминале which httpd)
   7. В списке нажмите httpdи выберите Block incoming connections.
   8. Хит OK.

   9. Перезагрузите брандмауэр:

      $ launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
      $ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist
      $ launchctl load /System/Library/LaunchAgents/com.apple.alf.useragent.plist
      $ sudo launchctl load /System/Library/LaunchDaemons/com.apple.alf.agent.plist
      

3. Ограничить PHP до корня документа. В php.ini:

   open_basedir = /Users/joao/Sites/:/var/tmp/
   

   ( /var/tmp/для сессий)

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

_{- Обратите внимание, что, поскольку мой активный язык на моей машине не совсем английский, знайте, что формулировка может быть немного другой (параметры меню и формулировка могут отличаться независимо от языка в различных версиях OS X).}

_{- Строки, начинающиеся с, $необходимо вводить в командной строке (Терминал или iTerm и т. Д.), С $удаленными.}

Я просто решил свою проблему, установив разрешения не только для DocumentRootкаталога, но и для всех его родительских каталогов. Вот как я это сделал .

(13) В доступе отказано

Ошибка 13 указывает на проблему с разрешениями файловой системы. То есть Apache был запрещен доступ к файлу или каталогу из-за неправильных разрешений. Как правило, это не означает проблемы в файлах конфигурации Apache.

Чтобы обслуживать файлы, Apache должен иметь соответствующие разрешения, предоставленные операционной системой для доступа к этим файлам. В частности, пользователь или группа, указанные в httpd.conf, должны иметь возможность читать все файлы, которые будут обслуживаться, и искать каталог, содержащий эти файлы, а также все родительские каталоги вплоть до корня файловой системы.

Типичные разрешения в Unix-подобной системе для ресурсов, не принадлежащих пользователю или группе, указанных в httpd.conf, будут 644 -rw-r - r-- для обычных файлов и 755 drwxr-xrx для каталогов или сценариев CGI. Вам также может понадобиться проверить расширенные разрешения (например, разрешения SELinux) в операционных системах, которые их поддерживают.

Если вы используете 2.4, код ошибки AH может дать вам больше информации здесь.

• AH00132: права доступа к файлу запрещают доступ к серверу
• AH00035: доступ запрещен, так как отсутствуют разрешения на поиск для компонента пути. Пример

Допустим, вы получили ошибку «Отказано в доступе» при доступе к файлу /usr/local/apache2/htdocs/foo/bar.html в Unix-подобной системе.

Сначала проверьте существующие разрешения на файл:

cd /usr/local/apache2/htdocs/foo
ls -l bar.htm

Исправьте их при необходимости:

chmod 644 bar.html

Затем сделайте то же самое для каталога и каждого родительского каталога (/ usr / local / apache2 / htdocs / foo, / usr / local / apache2 / htdocs, / usr / local / apache2, / usr / local, / usr):

ls -la
chmod +x .
cd ..
# repeat up to the root

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

namei -m /usr/local/apache2/htdocs/foo/bar.html Если в вашей системе нет namei, вы можете использовать parsepath. Это можно получить здесь.

Если все стандартные разрешения верны и вы все еще получаете ошибку «Отказано в доступе», вам следует проверить наличие расширенных разрешений. Например, вы можете использовать команду setenforce 0, чтобы отключить SELinux и проверить, исчезла ли проблема. Если это так, ls -alZ можно использовать для просмотра разрешений SELinux и chcon для их исправления.

В редких случаях это может быть вызвано другими проблемами, такими как проблема с правами доступа к файлам в другом месте вашего файла apache2.conf. Например, директива WSGIScriptAlias ​​не сопоставляется с реальным файлом. Сообщение об ошибке может быть неточным о том, какой файл был нечитаемым.

НЕ устанавливайте файлы или каталоги в режим 777, даже «просто для проверки», даже если «это просто тестовый сервер». Цель тестового сервера - сделать все правильно в безопасной среде, а не уйти от неправильной работы. Все, что он скажет вам, если проблема с файлами, которые на самом деле существуют.

CGI-скрипты

Хотя разрешение сценария CGI может выглядеть правильно, фактический двоичный файл, указанный в shebang, может не иметь необходимых разрешений для запуска. (Или какой-то каталог на его пути, проверьте с namei, как описано выше.)

(13) Отказано в доступе: прокси: HTTP: попытка подключения к 127.0.0.1:8080 (localhost) не удалась

Эта ошибка на самом деле не касается прав доступа к файлам или чего-то подобного. На самом деле это означает, что httpd было отказано в разрешении подключиться к этому IP-адресу и порту.

Наиболее распространенной причиной этого является SELinux, не позволяющий httpd устанавливать сетевые подключения.

Чтобы решить эту проблему, вам нужно изменить логическое значение SELinux (которое будет автоматически сохраняться при перезагрузке). Вы также можете перезапустить httpd для сброса прокси-сервера, хотя это не обязательно.

# setsebool -P httpd_can_network_connect 1

Следующие шаги работали для меня на High Sierra под управлением Apache 2.4

(Основано на следующем превосходном учебном пособии: http://www.cgi101.com/book/connect/mac.html , дополненном дополнительными шагами для определения различий в версиях).

1. Переместите файл в:

   /Library/WebServer/CGI-Executables
   

2. Убедитесь, что файл имеет разрешения на выполнение:

   ls -l  /Library/WebServer/CGI-Executables
   

   Если не использовать:

   chmod -x  /Library/WebServer/CGI-Executables/myfile.cgi
   

3. Раскомментируйте следующие строки в /etc/apache2/httpd.conf

   AddHandler cgi-script .cgi .pl
   
   AddType text/html .shtml
   AddOutputFilter INCLUDES .shtml
   
   LoadModule cgi_module libexec/apache2/mod_cgi.so
   

4. Также измените раздел каталога / Library / WebServer / CGI-Executables на:

   <Directory "/Library/WebServer/CGI-Executables">
    AllowOverride None
    Options ExecCGI
    Require all granted
   </Directory>
   

5. Затем перезапустите Apache:

   sudo apachectl -k restart
   

Почти с каждой новой версией macOS изменения будут потеряны, и вам придется переделывать работу и даже делать разные шаги для ее исправления. Ваш лучший друг - журналы Apache, расположенные в / var / log / apache2 / (/ var / log / apache2 / error_log)

Я использовал ACL для установки разрешений, следуя инструкциям в « Как установить разрешения для файлов и каталогов для Apache в Mac OS X », но все еще получал:

[Wed Feb 12 15:43:51 2014] [error] [client ::1] (13)Permission denied: access to /trace/trace.php denied (filesystem path '/Library/WebServer/Documents/trace/trace.php') because search permissions are missing on a component of the path

Затем я прочитал « (13) Отказано в разрешении » (ссылка на него содержится в ответе Жоао Рамоса ) и попытался добавить «выполнить» в ACL. Это сработало.

Перезагрузите компьютер! Это сработало для меня.

Но прежде всего я сменил пользователя под apache на себя (с _www), так как это локальная / тестовая среда. Так что в конечном итоге это как-то связано с разрешениями.

Затем перезагрузите компьютер, как Windows;).

OP описывает проблему, возникающую при попытке настроить локальную среду веб-сервера на Mac с использованием Apache, PHP и MySQL, с настраиваемым DocumentRoot, включая упоминание об использовании VirtualHost (vhost). ОП сообщает об ошибке 403 Forbidden при доступе к localhost.

В статье на coolestguidesontheplanet описывается, как настройка виртуальных хостов в Apache приводит к «потере локального хоста». Другими словами, коренная причина проблемы ОП может заключаться в неполной активации vhosts.

«Как только [виртуальные хосты] настроены, вы теряете свой старый корень документа, ранее находившийся в / Library / WebServer / Documents или доступный в браузере по адресу http: // localhost - вы получаете 403 Forbidden Error».

Далее в статье объясняется, как исправить localhost в среде vhost.

Add these lines to file /etc/apache2/extra/httpd-vhosts.conf:

   <VirtualHost *:80> 
   ServerName localhost 
   DocumentRoot /Library/WebServer/Documents/ 
   </VirtualHost>

В нем также объясняется, как устранить «проблемы с разрешениями для таких вещей, как обновления и аутентификация», связанные с «использованием папки Users / username / Sites для vhosts».

Instead of using the default UID _www, use your own User and Group.

In the terminal, enter command 

    id

Find your UID and GID. 
Update file httpd.conf
In section <IfModule unixd_module>
Change User and Group to your local UID and GID.

https://coolestguidesontheplanet.com/set-virtual-hosts-apache-mac-osx-10-10-yosemite/