Is there a restriction on the name 'directory'? Keep getting 403

Posted February 4, 2017 4.5k views


I have a DO droplet, set up my app via Serverpilot, running a CraftCMS install. Everything has been fine, but just hit an issue.
I’m trying to create a subfolder from my root called ‘directory’ so it would be accessed via However I keep getting a 403 error when trying to access this. It works fine on a local environment, but when pushed up I get the

“You don’t have permission to access /directory/ on this server.

Possible causes of this error include:

The request was forbidden by rules in the .htaccess file.
The directory you requested does not have an index.html or index.php file.
The permissions on the file or directory are incorrect.”

If i rename this folder to anything else, it works.

Just a bit stumped.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
5 answers


The error stating that you don’t have permission to access ./directory is where we’ll start. It all boils down to permissions.

From the CLI, cd to the directory above ./directory and run:

ls -al

Who owns ./directory? If Apache is, for example, running as www-data and ./directory is owned by root, then the user www-data won’t be able to read, write, or execute. In such a case, you’d need to make sure ./directory is owned by the same user and group as your other files (which, for security, should not be root).

The root user can read, write, or execute anything – other users, however, can not do the same for directories or files owned by root.

Thanks for the response. Ive just gone in and checked. The directory and subsequent index.html file have the exact same permissions as the other directories.?

  • @shorn

    Ok, so that eliminates potential permission issues. The next thing we’d need to do is to check your Apache configuration for the domain in question.

    Would it be possible for you to post the VirtualHost block for the domain you’re having issues with? There’s a few potential causes and viewing it directly would allow me to pinpoint the issue for you a little quicker than providing multiple potential scenarios.

    If you can post it between a code block I’ll be more than happy to work with you to get this resolved.

    • @jtittle - how would I go about getting that? As I mentioned, it’s a DO droplet thats set up via Serverpilot. One single app on the droplet.

      • @shorn

        If you used ServerPilot to deploy your application, you should of received a password for root unless you setup an SSH Key to access your Droplet, in which case you’d use the private key to login to SSH.

        For example, without an SSH Key:

        ssh root@DROPLET_IP

        … and with an SSH Key:

        ssh root@DROPLET_IP -I /local/path/to/private_key

        … where /local/path/to/private_key is where the private key exists on your local machine (i.e. Mac, Windows, Linux).

        Once inside we’d need to figure out how they’ve set things up for you. From reading over their site, parts state they install NGINX while others state that they install both NGINX and Apache.

        I’m not too familiar with their entire setup, though if they stick to using the standard package manager to install either or, then we can check to see if both or just one is installed.

        You can run:

        ls -al /etc/nginx


        ls -al /etc/apache2

        If both directories exist and are filled with configuration files, then they are most likely proxying requests from NGINX to Apache (which sort of complicates things for users that don’t work from the CLI often or at all, especially when issues pop up).

        The main directories we need to look at are:




        Those directories are where your configuration files are going to be for your domains (if they aren’t using custom directory structures).

        So what you’d do is open them using nano and post the contents:

        nano /etc/nginx/sites-available/example.conf


        nano /etc/apache2/sites-available/example.conf

OK, so it looks like I have both nginx and apache folders, but these are called apache-sp and ngix-sp (presumably as they are set up by Serverpilot.)
I dont have any ‘sites-available’ folders. I’ve managed to fine conf files in the vhosts.d folder. A file in here contains the following virtualhost block.

    Define DOCUMENT_ROOT /srv/users/serverpilot/apps/myapp/public
    Define PHP_PROXY_URL unix:/srv/users/serverpilot/run/myapp.php-fpm.sock|fcgi://localhost

    ServerAdmin webmaster@
    DocumentRoot ${DOCUMENT_ROOT}
    ServerName server-myapp

    ErrorLog "/srv/users/serverpilot/log/myapp/myapp_apache.error.log"
    CustomLog "/srv/users/serverpilot/log/myapp/myapp_apache.access.log" common

    RemoteIPHeader X-Real-IP
    SetEnvIf X-Forwarded-SSL on HTTPS=on
    SetEnvIf X-Forwarded-Proto https HTTPS=on

    SuexecUserGroup serverpilot serverpilot

    IncludeOptional /etc/apache-sp/vhosts.d/myapp.d/*.conf

That help at all?


Yes and no, but it let’s me know how they have things setup and confirms that they are indeed using NGINX to proxy requests over to Apache (hence port 81 in the VirtualHost block – that means NGINX is listening on port 80).

That said, nothing looks out of place in that specific configuration, so we may have to dig deeper and take a look at what’s inside of:


The line below is telling Apache to include additional configuration files from the above directory (using * means all files ending in .conf).

IncludeOptional /etc/apache-sp/vhosts.d/myapp.d/*.conf

In most cases, there’s a <Directory /path></Directory> block that defines overall permissions inside of the <VirtualHost></VirtualHost> block.

As a basic example, here’s what this would potentially look like:

<Directory />
    Options Indexes FollowSymLinks Includes ExecCGI
    AllowOverride All
    Require all granted
    Allow from all

The / in the above grants access from / down – a direct path could be used as well. If something like that doesn’t exist, and NGINX isn’t setup to limit directories, then that would be why you’re unable to access newly created directories.

NOTE: Don’t copy and paste the above in to you configuration for testing without changing / to a direct path. The above would assume /, or the root path. If you did want to test this out, you could replace / with:



<Directory /srv/users/serverpilot/apps/myapp/public>
    Options Indexes FollowSymLinks Includes ExecCGI
    AllowOverride All
    Require all granted
    Allow from all

There could also be something similar defined in an .htaccess file that limits directory browsing since Apache uses .htaccess files to handle user-defined configuration.

Thanks again. So I’ve found the directory block. it is as follows…

<Directory ${DOCUMENT_ROOT}>
    AllowOverride All
    Require all granted

    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_URI} !-f
    RewriteRule \.php$ - [R=404]

My htaccess file contains just…

<IfModule mod_rewrite.c>
    RewriteEngine On

    # Send would-be 404 requests to Craft
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} !^/(favicon\.ico|apple-touch-icon.*\.png)$ [NC]
    RewriteRule (.+) index.php?p=$1 [QSA,L]

which was added to remove the index.php from the urls.

I can’t see anything that’s out of place. The strange thing is that every other directory I create is fine. It’s only when I create one actually called ‘directory’. ?