Fixing "data directory not writable" errors with PHP 8.4+ FPM on Debian/Ubuntu

Symptom

After upgrading to PHP 8.4 (or later) using the php8.4-fpm (or newer) package from the popular deb.sury.org APT repository on Debian or Ubuntu, the product stops being able to write to its data directory — uploads, cache, logs, and other writable operations fail, even though file permissions and ownership look correct.

This typically affects installations where the product's application files (and its data directory) live under /usr/share/... — a common location for packages installed via .deb.

Cause

Starting with PHP 8.4, the php8.4-fpm.service systemd unit shipped by deb.sury.org includes additional security hardening directives (such as ProtectSystem=strict) that mount /usr as read-only for the php-fpm process. If the product's writable data directory is located anywhere under /usr (e.g. /usr/share/afterlogic/data), the web server user can no longer write to it, regardless of standard Unix file permissions.

Fix option 1 — allow write access via a systemd override (quick fix)

This opens a specific exception in the sandbox for your installation path.

Create a systemd override for the PHP-FPM service:
```
sudo systemctl edit php8.4-fpm
```
In the editor that opens, add:
```
[Service]
ReadWritePaths=/usr/share/afterlogic
```
(replace /usr/share/afterlogic with your actual installation path)

Reload systemd and restart the service:

sudo systemctl daemon-reload
sudo systemctl restart php8.4-fpm

Fix option 2 — move the data directory outside `/usr` (recommended)

Per the Filesystem Hierarchy Standard, /usr is meant to hold read-only, shareable application files, while variable/writable application state belongs under /var. Moving the data directory there avoids the read-only restriction entirely, is more robust against future hardening changes, and doesn't require weakening the sandbox.

Choose a writable location outside /usr, for example /var/lib/afterlogic, and create it:
```
sudo mkdir -p /var/lib/afterlogic
```
Move the existing contents of your current data directory there, then set ownership to the user your web server / PHP-FPM runs as:
```
sudo mv /usr/share/afterlogic/data/* /var/lib/afterlogic/
sudo chown -R www-data:www-data /var/lib/afterlogic
```
Create a file named inc_settings_path.php in the product's webmail root directory (next to index.php) with the following content:
```
<?php
define('AU_API_DATA_FOLDER', '/var/lib/afterlogic');
```
Restart PHP-FPM:
```
sudo systemctl restart php8.4-fpm
```

The product will now read and write all of its data at the new location, independent of any read-only restrictions placed on /usr.

Applies to

Any Debian/Ubuntu installation using PHP-FPM packages from deb.sury.org on PHP 8.4 or later, where the product's data directory resides under /usr. The same underlying issue and Fix option 2 also apply generally to any systemd-hardened PHP-FPM setup that restricts write access to /usr, regardless of distribution.