Como corrigir 403 no Apache interno do Mac OS X?

Estou tentando definir um ambiente local no meu novo MacBook Air 13 ": Apache embutido com meu próprio DocumentRoot, PHP e MySQL. Normalmente, atualizo /etc/hostsapenas para executar meus sites locais com um link permanente: local/examplePara referências, geralmente Verifica:

• Como transformar o Mac OS X Lion em um servidor web?
• Habilitando o Apache no Mac OS X Mountaion Lion
• Permissões do Apache

Desta vez eu estou simplesmente recebendo uma Forbidden 403 de erro cada vez que eu bati 127.0.0.1, localhostou local. Primeiro vi através do terminal que o Apache e o PHP estão em execução (mesmo que eu não consiga visualizar as páginas PHP); atualizei todas as permissões de acordo com as permissões do Apache ; agora estou apenas desesperado. Aqui estão as configurações relevantes do Apache:

• /etc/hosts( visualizar arquivo - adicionada uma linha)
• /etc/apache2/httpd.conf( visualizar arquivo - atualizado DocumentRoot)
• /etc/apache2/users/joao.conf( visualizar arquivo - criou este arquivo)
• /etc/apache2/extra/httpd-vhosts.conf( visualizar arquivo - atualizado VirtualHost)

Parece que o Apache está de alguma forma me negando acesso ao meu DocumentRoot(que por sinal é ~/Sites). Como ~/Sitesna verdade é um link simbólico, tentei atualizar DocumentRootcom os seguintes caminhos (todos apontando para o mesmo diretório):

• ~/Sites
• /Users/joao/Sites
• /Users/joao/Dropbox/Workflow/Sites(o diretório original )

Ainda jogando 403 . Alguma idéia de como corrigir / depurar isso?

Atualização rápida - eis a minha /var/log/apache2/joao.pt-error_logaparência:

[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

Eu tenho um alias especificado no servidor OSX apontando para um diretório de usuário. Passei muito tempo chmodding e mexendo com _www user, adicionando permissões executáveis ​​recursivamente, desinstalando macports e todo tipo de coisa tentando fazer com que isso funcionasse. Não faço ideia por que não estava funcionando.

Eventualmente, acabei de marcar a caixa de seleção "pasta compartilhada" no Finder para essa pasta e funcionou , no domínio especificado, com o php ativo, da maneira que eu queria. : / ... então foi fácil.

Eu atualizo para o macOSS Sierra , versão 10.12

Enfrento o mesmo problema, fiz duas coisas para corrigi-lo corretamente. A seguir estão minhas abordagens.

1) Verifique o arquivo " /private/etc/apache2/extra/httpd-userdir.conf ". mudança

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

para

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

2) ** E edite seu " /etc/apache2/httpd.conf"

mudança

Options FollowSymLinks Multiviews

para

Options FollowSymLinks Multiviews Indexes

finalmente, a raiz do seu documento será semelhante à seguinte,

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

3) Reinicie o apache

sudo apachectl restart

Ainda enfrentando o problema, verifique Como instalar o Apache no macOS Sierra 10.12

Geralmente, eu corrijo isso configurando o usuário do Apache para mim em ambientes locais e em máquinas em que o único usuário que usa o Apache sou eu. Em /private/etc/apache2/httpd.conf, defina o Userseu nome de usuário em _www, por exemplo:

User _www

->

User joao

E, em seguida, reinicie o Apache:

$ sudo apachectl restart

Etapas adicionais:

1. Se você tiver sessões ativas, eles fornecerão erros de permissão, pois ainda pertencem a eles _www. Possuí-los:

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

Implicações:

Depois disso, o Apache (e PHP et al.) Serão executados como você e obterão permissão de leitura / gravação para todos os arquivos que você possui permissão de leitura / gravação. Mas como esse é apenas um ambiente de desenvolvimento local, isso não deve ser um problema, a menos que você não tenha regras para bloquear o Apache no firewall e permita que arquivos questionáveis, como exploradores de arquivos, shells, scripts que possam conter vulnerabilidades, sejam executados no Apache; nesse caso, qualquer pessoa, incluindo seu vizinho de wifi público em um café, pode entrar http://<your IP>e fazer o que esses scripts permitirem.

De fato, você deve evitar isso, independentemente dos scripts executados ou mesmo se não definir o usuário do Apache para si mesmo, pois provavelmente não deseja que pessoas de fora aleatórias possam ver o conteúdo do seu localhost.

Prevenção:

1. Faça o Apache ouvir apenas o host local. Mais uma vez, em httpd.conf:

   Listen 80
   

   ->

   Listen 127.0.0.1:80
   

   E reinicie o Apache novamente:

   $ sudo apachectl restart
   

2. Desabilite o Apache no firewall do aplicativo (observe que você já o desabilitou se clicou Denyse / quando foi solicitado durante a primeira vez que o Apache foi executado):

   1. Abra System Preferences» Security & Privacy» Firewall.
   2. Clique no ícone de cadeado no canto inferior esquerdo e digite sua senha, se necessário.
   3. Ligue o firewall se estiver desativado.
   4. Clique em Firewall Options.
   5. Clique no +botão
   6. Pressione cmd ⌘+ ⇧ shift+ Ge digite /usr/sbin/httpde clique Add(se httpdnão aparecer lá, você pode procurá-lo no terminal which httpd)
   7. Na lista, clique httpde selecione Block incoming connections.
   8. Hit OK.

   9. Recarregue o firewall:

      $ 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. Restrinja o PHP à raiz do documento. Em php.ini:

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

   ( /var/tmp/é para sessões)

Use todas as três soluções para se proteger caso uma delas seja desativada por algum motivo.

_{- Observe que, como meu idioma ativo na minha máquina não é o inglês, as palavras podem ser um pouco diferentes (as opções de menu e as palavras podem ser diferentes, independentemente do idioma nas várias versões do OS X).}

_{- As linhas que começam com $precisam ser inseridas na linha de comando (Terminal ou iTerm etc.), com as $removidas.}

Acabei de resolver meu problema definindo permissões não apenas no DocumentRootdiretório, mas também em todos os diretórios pai. Foi assim que eu fiz .

(13) Permissão negada

O erro 13 indica um problema de permissões do sistema de arquivos. Ou seja, foi negado ao Apache acesso a um arquivo ou diretório devido a permissões incorretas. Geralmente, isso não implica um problema nos arquivos de configuração do Apache.

Para veicular arquivos, o Apache deve ter a permissão adequada concedida pelo sistema operacional para acessar esses arquivos. Em particular, o Usuário ou Grupo especificado em httpd.conf deve poder ler todos os arquivos que serão servidos e pesquisar no diretório que os contém, juntamente com todos os diretórios pai até a raiz do sistema de arquivos.

As permissões típicas em um sistema unix para recursos não pertencentes ao Usuário ou Grupo especificado no httpd.conf seriam 644 -rw-r - r-- para arquivos comuns e 755 drwxr-xrx para diretórios ou scripts CGI. Você também pode precisar verificar permissões estendidas (como permissões do SELinux) nos sistemas operacionais que as suportam.

Se você estiver executando o 2.4, o código de erro do AH pode fornecer mais informações aqui.

• AH00132: permissões de arquivo negam acesso ao servidor
• AH00035: acesso negado porque faltam permissões de pesquisa em um componente do caminho

Digamos que você recebeu o erro de permissão negada ao acessar o arquivo /usr/local/apache2/htdocs/foo/bar.html em um sistema unix.

Primeiro verifique as permissões existentes no arquivo:

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

Corrija-os se necessário:

chmod 644 bar.html

Faça o mesmo para o diretório e para cada diretório pai (/ 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

Em alguns sistemas, o utilitário namei pode ser usado para ajudar a encontrar problemas de permissões, listando as permissões ao longo de cada componente do caminho:

namei -m /usr/local/apache2/htdocs/foo/bar.html Se o seu sistema não possui namei, você pode usar o parsepath. Pode ser obtido aqui.

Se todas as permissões padrão estiverem corretas e você ainda receber um erro de permissão negada, verifique as permissões estendidas. Por exemplo, você pode usar o comando setenforce 0 para desativar o SELinux e verificar se o problema desaparece. Nesse caso, ls -alZ pode ser usado para visualizar a permissão do SELinux e o chcon para corrigi-las.

Em casos raros, isso pode ser causado por outros problemas, como um problema de permissão de arquivo em outro local do arquivo apache2.conf. Por exemplo, uma diretiva WSGIScriptAlias ​​não está mapeando para um arquivo real. A mensagem de erro pode não ser precisa sobre qual arquivo estava ilegível.

NÃO configure arquivos ou diretórios para o modo 777, mesmo "apenas para testar", mesmo que "seja apenas um servidor de teste". O objetivo de um servidor de teste é acertar as coisas em um ambiente seguro, não se safar de fazer errado. Tudo o que você dirá é se o problema está nos arquivos que realmente existem.

Scripts CGI

Embora a permissão do script CGI possa parecer correta, o binário real especificado no shebang pode não ter as permissões adequadas para ser executado. (Ou algum diretório em seu caminho, verifique com o nomei, conforme explicado acima.)

(13) Permissão negada: proxy: HTTP: tentativa de conexão com 127.0.0.1:8080 (host local) falhou

Este erro não é realmente sobre permissões de arquivo ou algo assim. O que realmente significa é que foi negada ao httpd a permissão para conectar-se a esse endereço IP e porta.

A causa mais comum disso é o SELinux, que não permite que o httpd faça conexões de rede.

Para resolvê-lo, você precisa alterar um valor booleano do SELinux (que persistirá automaticamente durante as reinicializações). Você também pode reiniciar o httpd para redefinir o trabalhador proxy, embora isso não seja estritamente necessário.

# setsebool -P httpd_can_network_connect 1

As etapas a seguir funcionaram para mim no High Sierra executando o Apache 2.4

(Com base no excelente tutorial a seguir: http://www.cgi101.com/book/connect/mac.html , atualizado com etapas adicionais para diferenças de versão)

1. Mova o arquivo para:

   /Library/WebServer/CGI-Executables
   

2. Verifique se o arquivo tem permissões de execução:

   ls -l  /Library/WebServer/CGI-Executables
   

   Se não usar:

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

3. Remova o comentário das seguintes linhas em /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. Altere também a sub-rotina Diretório "/ Library / WebServer / CGI-Executables" para:

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

5. Em seguida, reinicie o Apache:

   sudo apachectl -k restart
   

Quase a cada nova versão do macOS, as alterações se perdem e você precisará refazer o trabalho e executar etapas diferentes para corrigi-lo. Seu melhor amigo são os logs do Apache localizados em / var / log / apache2 / (/ var / log / apache2 / error_log)

Eu estava usando ACLs para definir permissões, seguindo as instruções em " Como definir permissões de arquivo e diretório para Apache no Mac OS X ", mas ainda obtendo:

[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

Depois li " (13) Permissão Negada " (vinculada à resposta de João Ramos ) e tentei adicionar "execute" à ACL. Isso funcionou.

Reinicie o seu computador! Isso funcionou para mim.

Mas, antes de tudo, eu havia mudado o usuário no apache para mim mesmo (de _www), pois é um ambiente local / de teste. Então, em última análise, tem algo a ver com permissões.

Em seguida, reinicie a máquina, assim como o Windows;).

O OP descreve um problema que ocorre ao tentar configurar um ambiente de servidor da Web local em um Mac, usando Apache, PHP e MySQL, com um DocumentRoot personalizado e incluindo uma menção ao uso do VirtualHost (vhost). O OP informa que está recebendo um erro 403 Proibido ao acessar o host local.

Um artigo no coolestguidesontheplanet descreve como a configuração de hosts virtuais no Apache causa "Losing Localhost". Em outras palavras, a causa raiz do problema do OP pode ser uma ativação incompleta dos fantasmas.

"Depois que os [hosts virtuais são] configurados, você perde sua raiz de documento mais antiga anteriormente em / Library / WebServer / Documents ou acessada no navegador em http: // localhost - você recebe um 403 Proibido Erro."

O artigo continua explicando como corrigir o host local em um ambiente vhost.

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

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

Ele também explica como corrigir "problemas de permissões com atualizações e autenticação" associadas a "usando a pasta Usuários / nome de usuário / Sites para 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/