Skip to content

v1.24.4 — CRITICAL: php-fpm ProtectSystem fix (account creation broken on updated servers)

Latest

Choose a tag to compare

@Tux82 Tux82 released this 09 Jun 05:18
· 2 commits to main since this release

⚠️ CRITICAL — please read, and enable automatic backups

This release fixes a system-wide bug that can silently break account creation, domain setup, and SSL on servers that were previously working perfectly. If you run iNetPanel, update and read this.

► Enable automatic backups now

Settings → Backups → enable daily automatic backups, and take a manual backup before updating. The failures in this bug are silent — operations report success while doing nothing — so a known-good backup is your safety net.

The bug — full details

  • What: php-fpm's systemd unit ships with ProtectSystem=full, which mounts /etc read-only for every process php-fpm spawns. The panel makes privileged system changes — useradd, Apache vhosts, PHP-FPM pools, vsftpd entries, Let's Encrypt certs — via root helpers launched by php-fpm, and sudo does not escape php-fpm's mount namespace, so all of those /etc writes fail.
  • Symptoms: creating an account fails with useradd: cannot lock /etc/passwd; try again later or Read-only file system; adding domains / issuing SSL can fail the same way. Until this release the scripts reported success anyway, leaving "phantom" accounts (a hosting_users row with no Linux user) that then block re-creating that username.
  • Why it appeared out of nowhere: ProtectSystem=full is part of the stock php-fpm unit; a routine PHP package update in the past few months enabled it on servers that were fine before. No panel change was involved — a working system simply stops being able to create accounts. It looks like a storage/permission problem but isn't — it happens identically on ext4 and ZFS.

The fix

A php-fpm drop-in sets ProtectSystem=true (keeps /usr and /boot read-only, allows /etc). New installs get it from the installer before php-fpm first starts; existing installs get it on update.

⚠️ Applying it on an already-affected server

Most servers need no action — the nightly auto-update (runs as root via cron, outside the sandbox) applies this fix automatically. Just make sure auto-update is enabled under Settings → Updates.

To apply it immediately, or if auto-update is off, run once from a root shell:

inetp panel_update      # or: php /var/www/inetpanel/scripts/panel_update.php

The web "Update Now" button cannot apply this particular fix — it runs inside php-fpm's read-only sandbox. After the fix applies, php-fpm stops sandboxing /etc and everything (including "Update Now") works normally again. If a username is stuck as a phantom account, delete its hosting_users row and re-create it.


Also in v1.24.4

  • create_user.sh now fails loudly when useradd fails (no more phantom accounts) — this is what finally surfaced the bug above.

Full changelog: v1.24.3...v1.24.4