22

I'm trying to set a local environment on my new MacBook Air 13": built-in Apache with my own DocumentRoot, PHP, and MySQL. I usually update /etc/hosts just to run my local websites with a pretty permalink: local/example. For references, I usually check:

This time I'm simply getting a 403 Forbidden error every time I hit 127.0.0.1, localhost, or local. First I saw through the terminal that both Apache and PHP are running (even though I can't view PHP pages); then I updated all permissions according to Apache permissions; now I'm just desperate. Here are the relevant Apache configs:

  • /etc/hosts (view file — added one line)
  • /etc/apache2/httpd.conf (view file — updated the DocumentRoot)
  • /etc/apache2/users/joao.conf (view file — created this file)
  • /etc/apache2/extra/httpd-vhosts.conf (view file — updated VirtualHost)

It looks like Apache is somehow denying me access to my DocumentRoot (which by the way is ~/Sites). Because ~/Sites is actually a symlink, I then tried to update DocumentRoot with the following paths (all pointing to the same directory):

  • ~/Sites
  • /Users/joao/Sites
  • /Users/joao/Dropbox/Workflow/Sites (the original directory)

Still throwing 403. Any ideas how to fix/debug this?

Quick update — here's what my /var/log/apache2/joao.pt-error_log looks like:

[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
16

I have an alias specified in OSX server pointing to a user directory. I spent a long while chmodding and messing with _www user, adding executable permissions recursively, uninstalling macports and all sorts of stuff trying to get this to work. No idea why it wasn't working.

Eventually, I just checked the "shared folder" checkbox in the Finder for that folder, and it worked, on the specified domain, with php active, the way I wanted it to. :/ ...so that was easy.

  • It didn't work for me. I created a folder /Sites (in my root / folder) and putted my files there, configuring the Alias and Directory options accordingly. Worked fine. – jpenna Feb 14 at 4:31
10

I update to macOSS Sierra, Version 10.12

I face the same issue, I did two things to fix it properly. Following is my approaches.

1) Please check "/private/etc/apache2/extra/httpd-userdir.conf" file. Change

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

to

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

2)**And edit your "/etc/apache2/httpd.conf"

change

Options FollowSymLinks Multiviews

to

Options FollowSymLinks Multiviews Indexes

finally your doc root will be look like the following,

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

3) Restart apache

sudo apachectl restart

Still you facing the problem, Kindly check How to Set up Apache in macOS Sierra 10.12

9

I generally fix this by setting the Apache user to myself in local environments and in machines where the only user who uses Apache is me. In /private/etc/apache2/httpd.conf, set User to your username from _www, e.g.:

User _www

->

User joao

And then restart Apache:

$ sudo apachectl restart

Additional steps:

  1. If you have active sessions, they are going to give permission errors since they are still owned by _www. Own them:

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

Implications:

After this, Apache (and PHP et al.) will run as you and will gain read/write permission to all of the files you have read/write permission. But since this is just a local development environment, that shouldn't be a problem unless you have no rules to block Apache in your firewall and let questionable files like file explorers, shells, scripts that may contain vulnerabilities run under Apache; in which case anyone including your public wifi neighbor in a cafe can enter http://<your IP> and do whatever those scripts let them to do.

In fact, you should prevent this regardless of the scripts you run or even if you don't set Apache user to yourself since you probably don't want random outsiders to be able to see the contents of your localhost.

Prevention:

  1. Make Apache listen only to localhost. Again, in httpd.conf:

    Listen 80
    

    ->

    Listen 127.0.0.1:80
    

    And restart Apache again:

    $ sudo apachectl restart
    
  2. Disable Apache in the application firewall (note that you may have already disabled it if you clicked Deny if/when it was asked during the first time you run Apache):

    1. Open System Preferences » Security & Privacy » Firewall.
    2. Click the lock icon to the lower left and enter your password if needed.
    3. Turn the firewall on if it's disabled.
    4. Click Firewall Options.
    5. Click the + button.
    6. Hit cmd ⌘ + ⇧ shift + G and enter /usr/sbin/httpd and click Add (If httpd doesn't show up there, you can look for it in the terminal by which httpd)
    7. In the list click httpd and select Block incoming connections.
    8. Hit OK.
    9. Reload the 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. Restrict PHP to the document root. In php.ini:

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

    (/var/tmp/ is for sessions)

Use all three solutions to secure yourself in case one of them gets disabled for some reason.

- Note that as my active language in my machine is not English right know, wording might be a little different (Menu options and wording can be different regardless of the language in various OS X versions).

- Lines starting with $ need to be entered in command line (Terminal or iTerm etc), with the $ removed.

5

I just solved my issue by setting permissions not only to the DocumentRoot directory, but also to all its parent directories. This is how I did it.

(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

  • 1
    Could you summarize the basic points in your answer? Thanks! – Matt Jul 3 '14 at 22:09
  • 2
    Granting access to all its parent directory would be a huge security infringement! – Julian F. Weinert Dec 24 '14 at 1:41
  • 1
    This answer is not useful. The workaround works for linux machines / configurations. OSX has a different directory structure, specially for apache (located in /Library/WebServer) the solution given is not for OSx, as the apple.stackexchange does. – Juan Feb 13 '16 at 16:01
3

The following steps worked for me on High Sierra running Apache 2.4

(Based on the following excellent tutorial: http://www.cgi101.com/book/connect/mac.html, updated with additional steps for version differences)

  1. Move the file to:

    /Library/WebServer/CGI-Executables
    
  2. Verify that the file has execution permissions:

    ls -l  /Library/WebServer/CGI-Executables
    

    If not use:

    chmod -x  /Library/WebServer/CGI-Executables/myfile.cgi
    
  3. Uncomment the following lines 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. Also change the Directory "/Library/WebServer/CGI-Executables" stanza to:

    <Directory "/Library/WebServer/CGI-Executables">
     AllowOverride None
     Options ExecCGI
     Require all granted
    </Directory>
    
  5. Then restart Apache:

    sudo apachectl -k restart
    

Almost with every new macOS version, the changes will become lost and you will need to redo the work, and even do different steps to fix it. Your best friend are the Apache logs located in /var/log/apache2/ (/var/log/apache2/error_log)

  • 1
    Not an answer but observation. #1 instruction above: Move the file to: What file? – Pam Aug 13 '18 at 22:53
0

I was using ACL's to set permissions, following the instructions in "How to Set File and Directory Permissions for Apache on Mac OS X", but still getting:

[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

Then I read "(13) Permission Denied" (linked to in João Ramos's answer) and tried adding "execute" to the ACL. That worked.

0

Restart your computer! This worked for me.

But first of all I had changed the user under apache to myself (from _www), since it is a local/test environment. So ultimately it has something to do with permissions.

Then restart the machine, just like Windows ;).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .