Recently I had a really hard time to figure out why I got a 403 response code when trying to access the assets I created in my symfony2 project. Using the --symlink parameter while running the assets:install command, symlinks are created to the Resources/public directories of all bundles. The assets should be accessible from the outside. The error log revealed the following:
My projects are located on a Strato server and I'm running Plesk 12 on it to manage the websites. In the past I already had trouble with different configurations overwritten or managed by Plesk, so my first guess was to check the website settings in the Plesk admin panel.
Following the Parallels KB article 27 I added the FollowSymLinks option to my projects web directory:
I tried different combinations of options and directories but none of them worked. One of the other options was -SymLinksIfOwnerMatch.
The config file which is actually edited by entering the additional HTTP server directives in Plesk is located in /var/www/vhosts/system/mydomain.tld/conf/vhost.conf. The next step was to verify that my customised vhost.conf file was actually loaded by entering invalid directives and running the apache config check. Still no success.
I made sure that the symlinks and the target directories are readable and executable. Using the following code I checked which user the webserver is running as:
I made sure that the user has read and exec rights on all of the paths and files. The error message in the log was still there. Analyzing it again I could state that the link target is for sure accessible and that symbolic links are definitely allowed!
Finally I checked the apache envvars configuration file in /etc/apache2/envvars and noticed that the webserver user and group are both www-data. Then I remembered that the current apache user is depending on the hosting account of Plesk, because PHP is running as a (Fast)CGI application. Maybe apache is trying to follow the symlinks as www-data user...
My project files all belong to the respective hosting account user. The group is always psacln which is a special Plesk group. Adding the psacln group to the www-data user solved the problem!
