---
title: "How to Fix a Blank White Screen in ISPConfig After a Sury PHP Upgrade (Read-Only Temp Folder)"
description: "Fix a blank white ISPConfig panel after a Sury PHP-FPM upgrade by adding a systemd ReadWritePaths override for the read-only temp folder."
url: "https://docs.noiz.ie/ispconfig/how-to-fix-a-blank-white-screen-in-ispconfig-after-a-sury-php-upgrade-read-only-/"
section: "ISPConfig"
categories:
  - "Control Panels > ISPConfig > ISPConfig Troubleshooting"
last_reviewed: "1 August 2026, against the ISPConfig release Noiz runs on Debian 12 with PHP-FPM from deb"
---

# How to Fix a Blank White Screen in ISPConfig After a Sury PHP Upgrade (Read-Only Temp Folder)

After upgrading PHP from the deb.sury.org repository, the ISPConfig control panel interface may return a completely blank white page. The browser shows no error, just an empty body. This article explains how to diagnose the fault, why standard permission checks show nothing wrong, and how to fix it properly with a one-line systemd override.

**Last reviewed:** 1 August 2026, against the ISPConfig release Noiz runs on Debian 12 with PHP-FPM from deb.sury.org. It complements the ISPConfig documentation; the fix itself is a systemd override, not an ISPConfig setting.

### Official Documentation Reference

- [systemd.exec(5): `ProtectSystem=`](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#ProtectSystem=): what each setting makes read-only for a service, including `/usr/`.
- [systemd.exec(5): `ReadWritePaths=`](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#ReadWritePaths=): the option that re-opens a single path for writing.
- [systemd.unit(5)](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html): how drop-in `.conf` files in a `.service.d/` directory extend a packaged unit.
- [DEB.SURY.ORG PHP repository setup script](https://packages.sury.org/php/README.txt): the maintainer's own instructions for the repository the PHP-FPM packages come from.

## Affected Environment

This issue was diagnosed and resolved on the following stack. The fix applies to any comparable ISPConfig host running PHP-FPM from deb.sury.org under systemd.

```
OS:          Debian GNU/Linux 12 (bookworm)
Kernel:      6.1.0-50-amd64
PHP-FPM:     PHP 8.2.32 (Sury build)
Web server:  nginx 1.22.1
ISPConfig:   3.3.1p1
systemd:     252
```

To capture the equivalent details on your own host, run:

```
echo "OS: $(. /etc/os-release; echo "$PRETTY_NAME")"
echo "Kernel: $(uname -r)"
echo "PHP-FPM: $(php -v | head -n1)"
echo "Web server: $(nginx -v 2>&1 || apache2 -v 2>&1 | head -n1)"
echo "ISPConfig: $(cat /usr/local/ispconfig/interface/lib/config.inc.php 2>/dev/null | grep -oP "ISPC_APP_VERSION'\s*,\s*'\K[^']+" || echo unknown)"
echo "systemd: $(systemctl --version | head -n1)"
```

## Symptom

The ISPConfig interface, which listens on port 8080 by default, loads to a blank white page. No error is displayed in the browser, and the login page is blank as well, so the panel cannot be reached at all.

## Step 1: Find the Real Error

A white screen is a PHP fatal error with `display_errors` switched off. The actual error lives in the web server's error log, not the browser. First identify which web server owns port 8080:

```
ss -tlnp | grep ':8080'
```

Then read the matching log. If nginx is serving the panel:

```
tail -n 60 /var/log/nginx/error.log
```

If Apache:

```
tail -n 60 /var/log/apache2/error.log
```

The fatal error will read:

```
PHP Fatal error: Uncaught InvalidArgumentException: Please make sure the folder
'/usr/local/ispconfig/interface/lib/classes/IDS/../../../temp' is writable in
/usr/local/ispconfig/interface/lib/classes/IDS/Monitor.php:159
```

That path resolves to `/usr/local/ispconfig/interface/temp`. This is not the same directory as `/usr/local/ispconfig/interface/web/temp`, which is the browser-accessible download area ISPConfig uses for exports such as language files. The fix below applies to the first path only.

The ISPConfig interface runs a PHPIDS intrusion-detection layer on every panel request, and it needs a writable working directory there for its scratch files and its `ids.log`. The layer is controlled by `/usr/local/ispconfig/security/security_settings.ini`, ISPConfig's panel security configuration file, and it is switched on for anonymous visitors by default, which is why the login page itself is blank before any credentials are entered. The remote API at `/remote/` on the same port skips the layer, so an API endpoint that still answers while the panel is blank is a useful early confirmation of this fault. When PHPIDS cannot write, it throws an uncaught exception and PHP fatals, producing the blank page.

## Step 2: The Trap, Permissions Look Correct

The obvious next step is checking permissions, and this is where the issue misleads. Confirm the directory ownership, the FPM pool user, and SELinux status. On an nginx panel install the control panel has its own PHP-FPM pool, `ispconfig.conf`, written by the ISPConfig installer and kept separate from the website pools:

```
ls -ld /usr/local/ispconfig/interface/temp
grep -E '^\s*(user|group)\s*=' /etc/php/8.2/fpm/pool.d/ispconfig.conf
getenforce 2>/dev/null || echo 'no SELinux'
```

On an affected host, everything checks out: the directory is owned by `ispconfig:ispconfig` with owner write permission, the FPM pool runs as `ispconfig`, and SELinux is not in play. The owning user has write access on disk, which is why a plain `chown` or `chmod` does not fix it.

## The Cause: systemd Sandboxing

The write is blocked above the filesystem, by systemd. Recent deb.sury.org PHP-FPM packages ship the service unit with `ProtectSystem=full`. That directive gives the service its own mount namespace in which `/usr`, `/boot`, and `/etc` are remounted read-only. Because the ISPConfig temp directory sits under `/usr/local/`, PHP-FPM sees it as read-only inside its private namespace, regardless of the real on-disk permissions.

This is not an ISPConfig defect. The Sury packages changed the service unit hardening in a way that the application's expected temp path did not account for.

## Step 3: Prove It

Reproduce the read-only behaviour in isolation. This test creates a throwaway systemd unit with the same directive and cleans itself up:

```
systemd-run --pty --property=ProtectSystem=full touch /usr/local/ispconfig/interface/temp/systest
```

A response of `Read-only file system` confirms systemd sandboxing is the blocker.

## Step 4: The Fix

`ReadWritePaths=` is the designed exception to `ProtectSystem`. It re-opens one specific path for writing while leaving the rest of the service hardening intact. Add it as a drop-in override, matching the PHP version to the running FPM service:

```
install -d -m 0755 /etc/systemd/system/php8.2-fpm.service.d
cat > /etc/systemd/system/php8.2-fpm.service.d/override.conf << 'EOF'
[Service]
ReadWritePaths=/usr/local/ispconfig/interface/temp
EOF
systemctl daemon-reload
systemctl restart php8.2-fpm
```

A **restart** is required, not a reload. Namespace properties only apply when the service process is re-spawned.

## Step 5: Verify

```
systemctl show php8.2-fpm -p ReadWritePaths
curl -k -s -o /dev/null -w '%{http_code}\n' https://localhost:8080/index.php
```

The temp path should appear in the `ReadWritePaths` output, and curl should return `302` (a redirect to the login page), confirming PHP now executes cleanly through to ISPConfig's routing. The panel answers on http or https depending on the choice made when ISPConfig was installed, so use `http://` in the curl check if no SSL vhost was created for the interface. Hard-refresh the browser (Ctrl+Shift+R) and the white screen is gone.

## Why Not Just Weaken the Hardening?

Alternatives such as setting `ProtectSystem=false` or editing the packaged unit file directly would also restore write access, but both are worse options. Disabling `ProtectSystem` entirely removes a meaningful security layer from PHP-FPM, and edits to the packaged unit file are overwritten on the next package upgrade. The drop-in override with `ReadWritePaths=` makes the narrowest possible exception and keeps every other protection active.

## Durability and Future Maintenance

The override lives in `/etc/systemd/system/`, entirely outside the ISPConfig tree, so it survives ISPConfig updates. systemd merges drop-ins on top of the packaged unit rather than replacing it, so it also survives normal PHP point-release upgrades.

Three points warrant attention going forward:

- If a future Sury unit change restructures the service, the drop-in could stop taking effect. The command `systemctl show php8.2-fpm -p ReadWritePaths` is the one-line canary for that check.
- If the panel is moved to a newer PHP-FPM version (for example 8.3), the same override must be created for that version's unit, since drop-ins are per-service. On nginx installs ISPConfig records the service and directory it uses under **System > Server Config**, on the **Web** tab, in the **PHP-FPM init script** and **PHP-FPM pool directory** fields, so confirm both there before writing the drop-in.
- Extra PHP builds registered under **System > Additional PHP Versions** are offered to websites, not to the control panel. Those services do not need this override. Only the service running the panel's own `ispconfig.conf` pool does.

## Related Articles

- [How to Fix the DEB.SURY.ORG Expired Signing Key Error (EXPKEYSIG) on Debian](/ispconfig/how-to-fix-the-debsuryorg-expired-signing-key-error-expkeysig-on-debian/), another issue originating from the deb.sury.org PHP repository.

## Need Help?

If the panel remains blank after applying the fix, or the error in your web server log differs from the one described here, contact the Noiz support team with the log output and the details captured in the environment commands above. Note that assistance on self-managed servers may be billable depending on your support plan.

---
Source: https://docs.noiz.ie/ispconfig/how-to-fix-a-blank-white-screen-in-ispconfig-after-a-sury-php-upgrade-read-only-/