Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

akicreative's avatar

Deploy Script issue with tmp/fpmlock and Isolation Mode

I have been using a server without issue on Digital Ocean for months. This past weekend I added a site in isolation mode on the same server. Well when I ran a deployment on a non-isolation site it would error: tmp/fpmlock error. It seems creating an isolation mode site changes the user/group of tmp/fpmlock. I went and changed it back to forge/forge and now it works again. But the isolation site won't deploy. Do I have to create a fpmlock folder for each isolation account with the appropriate user/group for each site? Seems this should be something that Forge should manage? Am I missing something?

/home/forge/.forge/provision-11158855.sh: line 32: /tmp/fpmlock: Permission denied

0 likes
4 replies
nckrtl's avatar

Have you updated the machine from ubuntu 18.04 to 20.04 by any chance? I had the same issue and had it solved by running

sudo sed -i "s/fs.protected_regular = .*/fs.protected_regular = 0/" /usr/lib/sysctl.d/protect-links.conf

This sets the fs.protected_regular value to 0 if it wasn't already.

Reload the update protect-links.conf with

sudo sysctl --system

Now you should no longer face the permission issue. I got this solution from James who is maintaining Forge.

5 likes
hosamalzagh's avatar

sudo rm /tmp/fpmlock

or change with new name

echo 'Restarting FPM...'; sudo -S service $FORGE_PHP_FPM reload ) 9>/tmp/any name

change fpmlock to any name

6 likes
ShengSlogar's avatar

If you're on Ubuntu 22, your file might be named 99-protect-links.conf, causing this error:

sed: can't read /usr/lib/sysctl.d/protect-links.conf: No such file or directory

If so, this will do the trick:

sudo sed -i "s/fs.protected_regular = .*/fs.protected_regular = 0/" /usr/lib/sysctl.d/99-protect-links.conf
sudo sysctl --system
4 likes
miking's avatar

Although these solutions seemed to work initially for me, I've had ongoing issues with it. One thing that seemed to help for a while was modify the script to explicitly change permissions on the lock file to ensure everyone has write access - ie:

( flock -w 10 9 || exit 1
    sudo -S service php8.2-fpm reload ) 9>/tmp/fpmlock
chmod 666 /tmp/fpmlock 2>/dev/null  		# Allow anyone to delete/modify the lock file

...but in some cases even this didn't do the trick. It's not ideal... but my latest attempt to solve the issue is to use directory locking instead of file locking - ie:

    if mkdir /tmp/fpmlockdir 2>/dev/null; then
        sudo -S service php8.2-fpm reload
        rmdir /tmp/fpmlockdir
    else
        echo "Failed to acquire lock for php8.2-fpm. Skipping..."
        exit 1
    fi

Please or to participate in this conversation.