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

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]
</Directory>

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]
</IfModule>

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’. ?

@shorn

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:

/etc/apache-sp/vhosts.d/myapp.d/

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
</Directory>

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:

/srv/users/serverpilot/apps/myapp/public

or

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

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.

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.

<VirtualHost 127.0.0.1:81>
    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
    ServerAlias myapp.co.uk

    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
</VirtualHost>

That help at all?

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

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.