Our web development setup on Ubuntu 20.04 looks as follows:
This usually leeds to the problem, that CLI commands (such as building the Theme) and actions via the web interface (such as changing Theme colors in the Admin Panel) clash with file permissions when for example the CLI creates a file which Apache later tries to change.
For years (i.e. with Magento 2, Contao, Laravel, ... before we started working with Shopware 6) we went well with the following command in the projects folder, using Linux ACLs:
export FOLDER=projects && sudo setfacl -Rm u:$USER:rwx $FOLDER && sudo setfacl -Rm u:www-data:rwx $FOLDER && sudo setfacl -Rm d:u:$USER:rwx $FOLDER && sudo setfacl -Rm d:u:www-data:rwx $FOLDER && sudo chmod 600 config
So ACLs are set properly and access works for the webserver as well as CLI commands .
And then came Shopware.
When building or changing the theme, the underlying Flysystem tries to set the visibility of files (the permissions). And while you can read/write files properly with the setfacl trick above, chmod is only possible for the file owner (which is "dev").
So we are getting:
detail: "Warning: chmod(): Operation not permitted"
meta: {trace: [,…], file:
"/home/dev/projects/example.com/vendor/league/flysystem/src/Adapter/Local.php",
We are wondering what is an elegant solution for this? How are others solving this?
Approaches we are considering:
www-data
www-data
scope for everythingWe decided to run Apache and FPM processed unter the logged in user. To avoid security issues, Apache should first be bound to 127.0.0.1:
in /etc/apache2/ports.conf
Listen 127.0.0.1:80
Listen ::1:80
<IfModule ssl_module>
Listen 127.0.0.1:443
Listen ::1:443
</IfModule>
Next, in /etc/apache2/envvars
we set the variables APACHE_RUN_USER
and APACHE_RUN_GROUP
to the logged in user dev
.
For FPM we set in all /etc/php/*/fpm/pool.d/www.conf
user = dev
group = dev
listen.owner = dev
listen.group = dev
Finally we restart apache and FPM processed and make sure the project files are owned by the logged in user.
You also might want to delete old sessions of the www-data user (or chown
them)
sudo rm /var/lib/php/sessions/*