Come risolvere 403 in Apache integrato in Mac OS X?

Ho appena risolto il problema impostando le autorizzazioni non solo sulla directory DocumentRoot , ma anche su tutte le sue directory madri. Questo è come l'ho fatto .

(13) Permission Denied

Error 13 indicates a filesystem permissions problem. That is, Apache was denied access to a file or directory due to incorrect permissions. It does not, in general, imply a problem in the Apache configuration files.

In order to serve files, Apache must have the proper permission granted by the operating system to access those files. In particular, the User or Group specified in httpd.conf must be able to read all files that will be served and search the directory containing those files, along with all parent directories up to the root of the filesystem.

Typical permissions on a unix-like system for resources not owned by the User or Group specified in httpd.conf would be 644 -rw-r--r-- for ordinary files and 755 drwxr-x-r-x for directories or CGI scripts. You may also need to check extended permissions (such as SELinux permissions) on operating systems that support them.

If you are running 2.4, the AH error code may give you more information here.

• AH00132: file permissions deny server access
• AH00035: access denied because search permissions are missing on a component of the path An Example

Lets say that you received the Permission Denied error when accessing the file /usr/local/apache2/htdocs/foo/bar.html on a unix-like system.

First check the existing permissions on the file:

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

Fix them if necessary:

chmod 644 bar.html

Then do the same for the directory and each parent directory (/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

On some systems, the utility namei can be used to help find permissions problems by listing the permissions along each component of the path:

namei -m /usr/local/apache2/htdocs/foo/bar.html If your system doesn't have namei, you can use parsepath. It can be obtained from here.

If all the standard permissions are correct and you still get a Permission Denied error, you should check for extended-permissions. For example you can use the command setenforce 0 to turn off SELinux and check to see if the problem goes away. If so, ls -alZ can be used to view SELinux permission and chcon to fix them.

In rare cases, this can be caused by other issues, such as a file permissions problem elsewhere in your apache2.conf file. For example, a WSGIScriptAlias directive not mapping to an actual file. The error message may not be accurate about which file was unreadable.

DO NOT set files or directories to mode 777, even "just to test", even if "it's just a test server". The purpose of a test server is to get things right in a safe environment, not to get away with doing it wrong. All it will tell you is if the problem is with files that actually exist.

CGI scripts

Although the CGI script permission might look correct, the actual binary specified in the shebang might not have the proper permissions to be run. (Or some directory on its path, check with namei as explained above.)

(13)Permission denied: proxy: HTTP: attempt to connect to 127.0.0.1:8080 (localhost) failed

This error is not really about file permissions or anything like that. What it actually means is that httpd has been denied permission to connect to that IP address and port.

The most common cause of this is SELinux not permitting httpd to make network connections.

To resolve it, you need to change an SELinux boolean value (which will automatically persist across reboots). You may also want to restart httpd to reset the proxy worker, although this isn't strictly required.

# setsebool -P httpd_can_network_connect 1

Ho un alias specificato nel server OSX che punta a una directory utente. Ho passato molto tempo a fare il chmodding con l'utente _www, aggiungendo le autorizzazioni eseguibili in modo ricorsivo, disinstallando macports e tutti i tipi di cose che cercavano di farlo funzionare. Non ho idea del motivo per cui non funzionava.

Alla fine, ho appena controllato la casella di controllo "cartella condivisa" nel Finder per quella cartella, e ha funzionato , nel dominio specificato, con php attivo, nel modo in cui lo volevo. : / ... così è stato facile.

In genere aggiusto questo impostando l'utente Apache su me stesso in ambienti locali e in macchine in cui l'unico utente che usa Apache sono io. In /private/etc/apache2/httpd.conf , imposta User nel tuo nome utente da _www , ad esempio:

User _www

- >

User joao

E quindi riavvia Apache:

$ sudo apachectl restart

Passaggi aggiuntivi:

1. Se hai sessioni attive, daranno errori di autorizzazione poiché sono ancora di proprietà di _www . Possedili:

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

Implicazioni:

Dopo questo, Apache (e PHP et al.) funzioneranno come voi e otterranno il permesso di lettura / scrittura per tutti i file che avete il permesso di lettura / scrittura. Ma poiché questo è solo un ambiente di sviluppo locale, questo non dovrebbe essere un problema a meno che tu non abbia regole per bloccare Apache nel tuo firewall e lascia che file discutibili come file explorer, shell, script che potrebbero contenere vulnerabilità eseguire sotto Apache; nel qual caso chiunque includa il tuo vicino di wifi pubblico in un bar può inserire http://<your IP> e fare tutto ciò che gli script gli permettono di fare.

In effetti, dovresti prevenirlo a prescindere dagli script che esegui o anche se non imposti l'utente Apache a te stesso poiché probabilmente non vuoi che gli estranei casuali possano vedere il contenuto della tua localhost .

Prevenzione:

1. Fai in modo che Apache ascolti solo su localhost. Di nuovo, in httpd.conf :

   Listen 80
   

   - >

   Listen 127.0.0.1:80
   

   E riavvia ancora Apache:

   $ sudo apachectl restart
   

2. Disabilita Apache nel firewall dell'applicazione (nota che potresti averlo già disabilitato se hai fatto clic su Deny se / quando è stato chiesto durante la prima esecuzione di Apache):

   1. Apri System Preferences » Security & Privacy » Firewall .
   2. Fai clic sull'icona del lucchetto in basso a sinistra e inserisci la password, se necessario.
   3. Attiva il firewall se è disattivato.
   4. Fai clic su Firewall Options .
   5. Fai clic sul pulsante + .
   6. Premi cmd ⌘ + ⇧ sposta + G e inserisci /usr/sbin/httpd e fai clic su Add (se httpd non mostra lassù, puoi cercarlo nel terminale di which httpd )
   7. Nell'elenco fai clic su httpd e seleziona Block incoming connections .
   8. Hit OK .

   9. Ricarica il 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. Limita PHP alla root del documento. In php.ini :

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

   ( /var/tmp/ è per le sessioni)

Usa tutte e tre le soluzioni per metterti in sicurezza nel caso in cui uno di loro venga disabilitato per qualche motivo.

_{- Si noti che poiché la mia lingua attiva nella mia macchina non è l'inglese correttamente noto, la formulazione potrebbe essere leggermente diversa (le opzioni di menu e la dicitura possono essere diverse indipendentemente dalla lingua in varie versioni di OS X).}

_{- Le righe che iniziano con $ devono essere immesse nella riga di comando (Terminal o iTerm ecc.), con $ rimossa.}

Aggiornamento a macOSS Sierra , versione 10.12

Affronto lo stesso problema, ho fatto due cose per sistemarlo correttamente. Di seguito sono i miei approcci.

1) Controlla il file " /private/etc/apache2/extra/httpd-userdir.conf ". Cambia

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

a

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

2) ** E modifica il tuo " /etc/apache2/httpd.conf"

cambia

Options FollowSymLinks Multiviews

a

Options FollowSymLinks Multiviews Indexes

infine la tua root del documento sarà simile alla seguente,

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

3) Riavvia apache

sudo apachectl restart

Stai ancora affrontando il problema, Gentilmente verifica Come configurare Apache in macOS Sierra 10.12

I seguenti passaggi hanno funzionato per me su High Sierra con Apache 2.4

(Basato sul seguente eccellente tutorial: link , aggiornato con passaggi aggiuntivi per le differenze di versione)

1. Sposta il file in:

   /Library/WebServer/CGI-Executables
   

2. Verifica che il file abbia le autorizzazioni di esecuzione:

   ls -l  /Library/WebServer/CGI-Executables
   

   Se non utilizzare:

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

3. Decommenta le seguenti righe in /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. Cambia anche la stanza Directory "/ Library / WebServer / CGI-Executables" in:

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

5. Quindi riavvia Apache:

   sudo apachectl -k restart
   

Quasi con ogni nuova versione di macOS, le modifiche andranno perse e sarà necessario rifare il lavoro, e persino fare diversi passaggi per risolverlo. I tuoi migliori amici sono i log di Apache situati in / var / log / apache2 / (/ var / log / apache2 / error_log)

Stavo usando le ACL per impostare le autorizzazioni, seguendo le istruzioni in " Come impostare le autorizzazioni per file e directory per Apache su Mac OS X ", ma continuando a ottenere:

[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

Poi ho letto " (13) Autorizzazione negata " (collegata a João Ramos's answer ) e provato ad aggiungere "execute" all'ACL. Ha funzionato.