TOPIC: SYSTEMD
Getting Grav Admin2 to write files with the correct permissions
19th September 2026
When I found that the find and replace functionality in the article editor offered by Grav's Admin2 plugin was next to unusable, I opted to do what I needed on the server using nano. However, I then discovered that was not possible without the sudo facility even though my user account was in the www-data group. Here is the command that discovered that 644 (owner with read and write permissions, the rest as read only) was being used instead of 664 (owner and group with read and write permissions, the rest as read only):
stat -c '%a %U %G %n' filename.md
Using -c switch to define a custom format, the output is like this for what I needed it to be:
664 www-data www-data filename.md
Unpacking the codes, %a provides the permissions in their octal or numeric form, %U gives the owner, %G is the associated group and %n is the file name. Though I manually set the permissions, I found that they kept changing whenever a file was updated from the user interface. It appears that the file is copied to a different area and then moved back when edits have been completed.
If I had thought that this was going to be resolved by finding the right setting in the Grav configuration I was about to be disappointed. The actual solution turned out to be in very different place: the web server systemd service settings.
PHP-FPM
If the PHP-FPM service was being used, then things might have been simpler. The first step is to add a systemd override by opening up the service configuration:
sudo systemctl edit php8.3-fpm
Near the top of the file, add these lines (make sure that they are above any line that says everything gets deleted below it). Then, save the file.
[Service]
UMask=0002
Following that, restart the service (this is for version 8.3; clearly, the version number will need changing for any future release):
sudo systemctl restart php8.3-fpm
Next, it is time to check that the override is in place by using this command:
systemctl show php8.3-fpm -p UMask
When you see a result like the one below, Grav should be producing files with rw-rw-r-- or 664 permissions through the Admin2 editor. That is how it is with a Nginx set up that I have with PHP-FPM in action on there. What is happening is that it takes the likes of 777 and makes it 775; if the setting were 0022 (the default, it would appear to me), you would then get 755.
UMask=0002
Apache MOD-PHP
However, the issue initially surfaced on an Apache web server, and it took a while for the solution to be found. Confusingly, both PHP-FPM and MOD-PHP were on there. Then, it was a question of finding which one was in action because the latter is part of Apache and the former is a separate service.
Trying the PHP-FPM override described above did not work, which hinted that something else was needed. That was to follow a similar process to that for PHP-FPM, only to do it for Apache this time around. The first step to add the override after opening the relevant file is as follows:
sudo systemctl edit apache2
As before, these lines need to go near the top of the file, above any line warning of the loss of any changes made below it, before it is saved:
[Service]
UMask=0002
Then, it is time to restart the service:
sudo systemctl restart apache2
Next, the override status needs to be probed:
systemctl show apache2 -p UMask
Getting this result from the above command again demonstrates that all should be in order, which it was in my case:
UMask=0002
After all that, it may be time to switch from MOD-PHP to PHP-FPM anyway. At least, it guarantees configuration consistency and separates PHP interpretation from normal web server activities as well.