• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Apache does not apply .htaccess directives for certain files after migration through Plesk Migrator

SKDamon

Basic Pleskian
Username:

TITLE

Apache does not apply .htaccess directives for certain files after migration through Plesk Migrator

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

root@rootsrv2 ~ # plesk -v
Product version: Plesk Obsidian 18.0.63.3
OS version: Ubuntu 22.04 x86_64
Build date: 2024/08/25 09:00
Revision: 01c517a618efcbc25c8b7bd56989e6216be9172a
Plesk Migrator Version 2.26.7-1496

PROBLEM DESCRIPTION

After a migration through Plesk Migrator extension, hosting options or nginx configuration is set incorrectly leading to nginx handling static (media) files directly without proxying to apache, or apache not processing .htaccess files on its own. This causes websites that rely on .htaccess files functioning to break.

I've migrated from an older server:
Product version: Plesk Obsidian 18.0.63.3
OS version: Ubuntu 20.04 x86_64
Build date: 2024/08/25 09:00
Revision: 01c517a618efcbc25c8b7bd56989e6216be9172a
Plesk Migrator Version 2.26.7-1496

The .htaccess directives that shoud add CORS (or any other) headers to certain files do not work after migration.
After migration, the "Smart static files processing" option under Apache&Nginx settings on the domain is unchecked.
When enabling this option, applying, disabling and applying again, the website works as expected, as in the .htaccess file is correctly processed by apache and headers are being added in the HTTP response.

The source server does not have nginx installed. To me it seems like the "Smart static files processing" or "Serve static files directly by nginx" option is actually enabled in the background, although the Plesk WebUI does show both options as unchecked after migration, or that the nginx proxy strips headers set by apache?

STEPS TO REPRODUCE

See: Issue - htaccess header missing

1. Create domain on SRV01 (optionally add IP + hostname to client's HOSTS file)
2. Add a .htaccess file in the document root with the following content:
Apache config:
Header add X-Custom-Test "*"
<FilesMatch "\.(jpeg|jpg|png|svg|pdf|mp4|gif)$">
    Header add X-File-Matched "true"
</FilesMatch>
3. Upload a test.png file to the document root
4. Verify expected result (headers are set correctly) from a client: curl -v -s http://headers.test/test.png 1>/dev/null
5. On SRV02, open the Plesk Migrator extension, migrate the test domain (all default values) from SRV01
6. Verify actual result (headers are missing) when requesting against SRV02 (update HOSTS file)
7. Turn on "Smart static files processing" in domain's Apache&nginx settings
8. Verify headers are still missing from SRV02 (but response size changed, indicating nginx solely handles the request now?)
9. Turn off "Smart static files processing" in domain's Apache&nginx settings
10. Verify headers are correctly set

ACTUAL RESULT

user@localhost$ curl -v -s http://headers.test/test.png 1>/dev/null
* Trying W.X.Y.Z:80...
* TCP_NODELAY set
* Connected to headers.test (W.X.Y.Z) port 80 (#0)
> GET /test.png HTTP/1.1
> Host: headers.test
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx
< Date: Fri, 30 Aug 2024 07:25:18 GMT
< Content-Type: image/png
< Content-Length: 40633
< Last-Modified: Fri, 30 Aug 2024 07:16:07 GMT
< Connection: keep-alive
< ETag: "66d171b7-9eb9"
< X-Powered-By: PleskLin
< Accept-Ranges: bytes
<
{ [1440 bytes data]
* Connection #0 to host headers.test left intact

EXPECTED RESULT

user@localhost$ curl -v -s http://headers.test/test.png 1>/dev/null
* Trying W.X.Y.Z:80...
* TCP_NODELAY set
* Connected to headers.test (W.X.Y.Z) port 80 (#0)
> GET /test.png HTTP/1.1
> Host: headers.test
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx
< Date: Fri, 30 Aug 2024 07:28:06 GMT
< Content-Type: image/png
< Content-Length: 40633
< Connection: keep-alive
< Last-Modified: Fri, 30 Aug 2024 07:16:07 GMT
< ETag: "9eb9-620e15d669bc0"
< Accept-Ranges: bytes
< X-Custom-Test: *
< X-File-Matched: true

< X-Powered-By: PleskLin
<
{ [1105 bytes data]
* Connection #0 to host headers.test left intact

ANY ADDITIONAL INFORMATION

Hosting Settings for the domain on source server:
PHP Handler: 8.3.10 (Dedicated FPM) - nginx is not installed so it's Apache
Apache&nginx: All defaults, nginx options missing because it's not installed

Hosting Settings on the target server after migration:
PHP Handler: 8.3.10 (Dedicated FPM - Apache)
Apache&nginx: Same as source w/ additional nginx Settings: Proxy Mode on

When migrating there is a list of errors due to different Apache modules and Plesk extensions being available, none of which I'd suspect would cause interference with nginx & apache's .htaccess processing:

Failed to dump the following data: Subscription (headers.test): Web server settings. Not all data may be migrated.
Error message: Command execution failed on the source server 'source' (5.35.251.254) with non-zero exit code.
command: /opt/psa/admin/sbin/nginxmng --status
exit code: 1
stdout: ***hidden***
stderr: ***hidden***
Service plan 'Unlimited' on source server has PHP handler
that is not installed on the target server: default OS PHP for PHP 7.4 running in FastCGI mode.
Another PHP handler was selected for that service template: default Plesk handler for PHP 7.4.33 running in FastCGI mode
To resolve the issue, it is recommended to do one of the following:
- Install and enable such PHP handler to target server.
- Ensure that PHP handler that was selected automatically is fine for migrated web sites.
- Select appropriate PHP handler in service template once migration is finished
and synchronize the changes to subscriptions.
The following Apache modules are not installed on the destination server: perl, php7.0, php7.4.
Please install and turn on these modules in Plesk to prevent some possible problems.
The following Apache modules are disabled on the destination server: auth_digest, authn_dbd, authz_groupfile, dav, dav_fs, dav_lock, dbd, log_debug, mpm_prefork, passenger, slotmem_shm, vhost_alias.
Please turn on these modules in Plesk to prevent some possible problems.
The component mod_perl is not installed on the destination server. mod_perl will be unavailable for all restored objects.
The following subscriptions are affected by the issue:

headers.test

Plesk extension 'panel-ini-editor' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'panel-ini-editor' on target Plesk
Plesk extension 'scheduled-backups-list' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'scheduled-backups-list' on target Plesk
Plesk extension 'advisor' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'advisor' on target Plesk
Plesk extension 'site-import' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'site-import' on target Plesk
Plesk extension 'dgri' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'dgri' on target Plesk
Plesk extension 'repair-kit' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'repair-kit' on target Plesk
Plesk extension 'monitoring' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'monitoring' on target Plesk
Plesk extension 'grafana' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'grafana' on target Plesk
Plesk extension 'heavy-metal-skin' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'heavy-metal-skin' on target Plesk
Plesk extension 'social-login' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'social-login' on target Plesk
Plesk extension 'domain-connect' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'domain-connect' on target Plesk
Plesk extension 'xovi' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'xovi' on target Plesk
Plesk extension 'revisium-antivirus' not installed on target Plesk, data of this extension will not be migrated
Install Plesk extension 'revisium-antivirus' on target Plesk

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
@SKDamon I have forwarded the report to our engineers for investigation and they concluded that on a test target, Smart static files processing is enabled by default, and there is no way to disable it on the service plan level, unless an event handler is created as per https://support.plesk.com/hc/en-us/articles/13499730989207. So this seems expected. Would you mind confirming how did you achieve the setup when it’s disabled so I can pass that information to our team for further review? Thanks in advance.
 
I had the exact same issue. For me re-enabling the "Smart static files processing" did not work. After a lot of research I tried to change "preferred domain" in the hosting settings.
I changed it from "none" to the actual domain and suddenly everything works fine again. I used "none" for years on every of my sites and also the old server of course also uses "none".
When I switch back from the domain to "none" again, it stops working again. So my "preferred domain" is the actual domain now.
 
Back
Top