Could not sign in after update to PHP 8.4

Self-Hosted | v5
1

Version v5.13.24

Environment - Ubuntu Server 24.04.4

Describe the bug

Could not sign in after upgrade to PHP 8.4. Received error 500 in the browser. I solved the problem after troubleshooting and want to share notes for others experiencing the same.

Steps To Reproduce

**** Prerequisites ****
php8.4-bcmath php8.4-intl php8.4-curl php8.4-zip php8.4-gd php8.4-xml php8.4-mbstring php8.4-mysql php8.4-fpm php8.4-mysql php8.4-lapd

**** Select php version ****
sudo update-alternatives --config php

**** update an entry and the socket link ****
/etc/nginx/sites-available/nginx-ninja.conf

client_max_body_size 20M;
fastcgi_pass unix:/run/php/php8.4-fpm.sock;

sudo systemctl reload nginx

**** Modify both php.ini in these locations ****
/etc/php/8.4/cli/php.ini
/etc/php/8.4/fpm/php.ini

upload_max_filesize = 20M
post_max_size = 20M
memory_limit = 2G

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

**** Clear out the php service and restart ****

sudo systemctl stop php8.4-fpm
sudo umount -l /tmp/systemd-private--php8.4-fpm.service- 2>/dev/null || true
sudo rm -rf /tmp/systemd-private--php8.4-fpm.service-
sudo systemctl start php8.4-fpm

**** Set ownership, permissions and writeable ****
*
sudo chown -R www-data:www-data /usr/share/nginx/ninja
*
sudo find /usr/share/nginx/ninja -type d -exec chmod 755 {} ;
sudo find /usr/share/nginx/ninja -type f -exec chmod 644 {} ;
*
sudo chmod -R 775 /usr/share/nginx/ninja/storage
sudo chmod -R 775 /usr/share/nginx/ninja/bootstrap/cache

*** test if a file is accessible***
sudo touch /usr/share/nginx/ninja/storage/logs/test.log

**** Setting up local temp directories to eliminate OS based restrictions ****

sudo rm -rf /usr/share/nginx/ninja/storage/framework/cache/data/*
sudo rm -rf /usr/share/nginx/ninja/storage/framework/views/*

sudo mkdir -p /usr/share/nginx/ninja/storage/framework/cache/data
sudo mkdir -p /usr/share/nginx/ninja/storage/framework/sessions
sudo mkdir -p /usr/share/nginx/ninja/storage/framework/views
sudo mkdir -p /usr/share/nginx/ninja/storage/app/tmp

sudo chmod -R 775 /usr/share/nginx/ninja/storage
sudo chmod -R 777 /usr/share/nginx/ninja/storage/framework/views
sudo chmod -R 777 /usr/share/nginx/ninja/storage/app/tmp

sudo chown -R www-data:www-data /usr/share/nginx/ninja/storage
sudo chown -R www-data:www-data /usr/share/nginx/ninja/storage/framework/views

**** Edit the file entries ****

/usr/share/nginx/ninja/.env

APP_ENV=local // for debugging
APP_DEBUG=“true” // for debugging

QUEUE_CONNECTION=database
TMPDIR=“/usr/share/nginx/ninja/storage/app/tmp”
TEMP=“/usr/share/nginx/ninja/storage/app/tmp”
FRAMEWORK_CACHE_DRIVER=file
VIEW_COMPILED_PATH=/usr/share/nginx/ninja/storage/framework/views

**** Edit the file entries to release restrictions or enable file writing ****

/lib/systemd/system/php8.4-fpm.service

ProtectSystem=full
ReadWritePaths=/usr/share/nginx/ninja/

**** Test script to see if the location is served to the browser and files are writeable ****

sudo editor /usr/share/nginx/ninja/public/test-write.php

** Create php file **
$dir = ‘/usr/share/nginx/ninja/storage/framework/views’;
echo "Testing directory: " . $dir . “
”;
echo "Is writable? " . (is_writable($dir) ? ‘YES’ : ‘NO’) . “
”;
$tmp = tempnam($dir, ‘test_’);
echo "Temp file created: " . ($tmp ? $tmp : ‘FAILED’);
*

**** Clear and reconfigure artisan ****
sudo -u www-data php8.4 artisan view:clear
sudo -u www-data php8.4 artisan config:clear
sudo -u www-data php8.4 artisan optimize:clear
sudo -u www-data php8.4 artisan optimize
sudo -u www-data php8.4 artisan config:cache

**** Clear Bootstrap caches ****
sudo rm -f /usr/share/nginx/ninja/bootstrap/cache/config.php
sudo rm -f /usr/share/nginx/ninja/bootstrap/cache/services.php
sudo rm -f /usr/share/nginx/ninja/bootstrap/cache/packages.php

Expected Behavior

Additional context

Screenshots

Logs

1 Like
2

Hi,

Thanks for sharing this!

3

Sure! It was just a frustrating exercise I don’t wish on anybody. Hope someone get’s use out of it.

4

+++
commercial block on
+++

Glad you got it working again.

This thread is pretty much the reason I started building INmanage.

From an operations point of view, this is the scary part: PHP changed, login breaks, you get a 500, and then you’re in the shell checking ownership, permissions, cache, queues, storage, vendor files, config basically hoping you hit the right thing in the right order.

That is a lot of manual work for something that should not be your game at all.

That’s why I’ve written INmanage. It is meant to make this boring stuff repeatable:

install in minutes, update in minutes, have: backups, preflight checks, cache cleanup, queue restart, health checks, rollback paths, notifications, offsite-backups … just ops.

Nothing magic. Just less guessing. And a litte added magic tools.

The real cost to updates is the six hours you lose afterwards when something weird happens and you have to remember which chmod, chown, cache clear or queue restart fixed it last time.

  • Installation takes minutes
  • Getting jiggy with it same
  • Saves tons of hours.

+++
commercial block off
+++

5

Turns out the crux of the issue is the systemd’s service sandboxing (ProtectSystem, PrivateTmp, etc.) trips up self-hosters because the standard file permissions (chmod/chown) look perfect, yet the application still acts like it’s locked out.

Editing the systemctl .service file was probably all that was needed in this case:

sudo systemctl edit php8.4-fpm.service

and adding

[Service]
ReadWritePaths=/usr/share/nginx/ninja

allows the php to write it’s files and workaround the issue of being prevented doing so by systemd.

This is likely the work around for php8.5 too, but I haven’t tested it yet.

1 Like