DirectAdmin 1.702

I have both fail, and I update the permission for /var/www/webapps/ to 755, still not working. Any particular I have to look at?
cgi.fix_pathinfo controls how PHP-FPM splits the URL between the actual script and the following PATH_INFO. The new static.php system introduced in Roundcube 1.7 works exactly this way: the URL /roundcube/static.php/skins/elastic/styles/styles.min.css means "execute static.php and pass /skins/elastic/styles/styles.min.css as PATH_INFO."

With cgi.fix_pathinfo=0, PHP-FPM does not correctly separate the two parts. Instead, it attempts to resolve and execute the entire path as a script, which directly points to skins/elastic/styles/styles.min.css—a file located outside public_html/ (as we previously verified, skins/ is a sibling directory, not a subdirectory).

Apache therefore correctly denied access (HTTP 403) to a path outside its authorized <Directory> scope, and did so silently because this was not a classic Apache access denial but rather a FastCGI path resolution failure.

This explains everything:

  • Why the login page worked (that request does not use PATH_INFO).
  • Why all assets failed in the same way, including static files.
  • Why rolling back to version 1.6.x appeared to have the "same issue" even though it was actually two different bugs overlapping (cgi.fix_pathinfo plus the changed/expires_at database schema issue that we identified in the logs).
  • Why manually moving the files changed nothing: it was never a path, symlink, or permissions issue.

One final point to check before closing the case: this setting is probably defined in the global php.ini used by the shared PHP-FPM pool for all your domains. Verify that there isn't a pool-specific override for the webapps pool that could reset it back to 0:

grep -rn "cgi.fix_pathinfo" /usr/local/php83/etc/php-fpm.d/*.conf 2&gt;/dev/null<br>
If nothing is returned, you're fine—the global php.ini setting applies everywhere.
 
Back
Top