DirectAdmin 1.702

[AlouiKhaled]

Please don't reply to my messages. I checked everything before posting on the forum. Your message is a waste of time.

THE SOLUTION
IN php.ini change cgi.fix_pathinfo from 0 to 1 its working

 

[AlouiKhaled]

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.

 

[AlouiKhaled]

Please don't reply to my messages. I checked everything before posting on the forum. Your message is a waste of time.

THE SOLUTION

 

[Strator]

Ever since this update, I am having problems with forwarded emails not being scanned by Spamassassin. It is still working within the same domain ([email protected] forwarded to [email protected] is scanned), but when the mail is forwarded from a different domain (i.e. [email protected] forwarded to [email protected]), the mail isn't checked for spam anymore.

Note that the forwarding domains have spamassassin turned OFF so the spam used to be scanned at the incoming domain (using that configuration file, bayes database and spam folder). So this may look similar, but is different from having the mail scanned by the forwarding domain.

Although I don't see anything on my end that could be causing the problem, it would be great to get confirmation from someone else with this setup - and then to find out if it's a bug or maybe intended behavior. Thanks!