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

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

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.