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.

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, 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.