/usr/local/ispconfig/interface/temp not writable error

This old error has suddenly resurfaced after a sequence of recent upgrades — I cannot pinpoint precisely which one, but it could have been a PHP upgrade:

Code:

2026/05/26 00:58:50 [error] 3401#3401: *6784862 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught InvalidArgumentException: Please make sure the folder '/usr/local/ispconfig/interface/lib/classes/IDS/../../../temp' is writablein /usr/local/ispconfig/interface/lib/classes/IDS/Monitor.php:159
Stack trace:
#0 /usr/local/ispconfig/interface/lib/classes/ids.inc.php(117): IDS\Monitor->__construct()
#1 /usr/local/ispconfig/interface/lib/app.inc.php(420): ids->start()
#2 /usr/local/ispconfig/interface/web/index.php(32): require_once('...')
#3 {main}
  thrown in /usr/local/ispconfig/interface/lib/classes/IDS/Monitor.php on line 159" while reading response header from upstream, client: 2001:8a0:4a87:d000:8463:740b:be9d:67a6, server: _, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/var/lib/phpXXX-fpm/ispconfig.sock:", host: "myserver.example.com:8080"

Note that the error — but not the solution! — was reported in the Softaculous forums back in 2018: https://www.softaculous.com/board/index.php?tid=14205

Now, ISPConfig3 hasn't supported Softaculous for quite a while now, so this cannot be related to that.

Tinkering with the permissions of /usr/local/ispconfig/interface/temp does not lead anywhere. The culprit is, indeed, line 159 of Monitor.php, which calls is_writable() on that path, chokes, and dies. Which, in turn, means: no ISPConfig3 at all, just an error 500 and the above stack trace.

The system is correctly determining the path. I wrapped the concatenation on the lines before using realpath(), which returns /usr/local/ispconfig/interface/temp, exactly as expected; and file_exists() called on that will also return TRUE — again, as expected. That also confirms that the FastCGI PHP subsystem is correctly configured with open_basedir and so forth, or else it wouldn't find the directory, much less be able to write to it.

As the old saying goes, 90% of all Unix issues are bad permissions "somewhere".

But since my time is limited, and the experiments I made lead to no permanent solution, much less figuring out what exactly is wrong, why, or where, I simply used the brute-force approach: commented out the check. For the sake of detecting something, I kept the file_exists() and the realpath() wrapping around: they don't hurt and canonicalise the path (always a good idea when "something" is adding those /../... you don't want anyone to devise a script to punch through all the security and be able to force Monitor.php to start writing on where it shouldn't... even if it's very unlikely such a thing may happen.

My only reason for posting this is to wonder
a) If someone else "suddenly" started seeing the same error again (FYI, I'm using Ubuntu 24.04.4 LTS with Nginx);
b) If that error was reported back in 2018 and someone has access to whatever tickets may have been opened back then and subsequently closed.

For now, well, I prefer some missing functionality (logs from Monitor.php, I presume...) than not having ISPConfig3 starting at all.

Thanks in advance for any insights!

 

There is a recent thread (or may be two about this) and it relates to Ondrej Sury php repo that we are using, and one of them has suggested a workaround, so try to search on that.