Attachment handling has some new problems

[apecity]

We're using 1.8.101 on Ubuntu and nginx, installed with the script.

Email has an attached Excel (.xlsx) file. When we click on the download link, a new, blank tab is shown (Firefox), or the system tries to download it as an .htm file for some reason (Chrome). See attached video grab, as I know that sounds weird. If we click 'Download all', a zip files is successfully created, and we can download and open it.

/var/www/html/storage/logs/web-server.log has this error when we try downloading the Excel file:
2023/10/09 21:36:20 [error] 5304#5304: *1257256 open() "/var/www/html/public/storage/attachment/6/3/1/Book1-3.xlsx" failed (2: No such file or directory), client: 113.11.246.207, server: service.fr8.vu, request: "GET /storage/attachment/6/3/1/Book1-3.xlsx?id=37286&token=253c9fa8aca6576aaf8bc1371ef4bbeb HTTP/1.1", host: "service.fr8.vu", referrer: "https://service.fr8.vu/conversation/8238?folder_id=3"

On the filesystem I did find /var/www/html/storage/app/attachment/6/3/1/Book1-3.xlsx, but it doesn't appear to be in the location where the server is looking.

In the last update, the instructions read to add this 'location' block to the nginx config. Seems too coincidental to me that this isn't related. We copied/pasted it in, and no syntax errors were thrown when we added it. Maybe we installed it incorrectly?

    location ~* ^/storage/.*\.((?!(jpg|jpeg|jfif|pjpeg|pjp|apng|bmp|gif|ico|cur|png|tif|tiff|webp|pdf|txt|diff|patch|json|mp3|wav|ogg|wma)).)*$ {
        add_header Content-disposition "attachment; filename=$1";
        default_type application/octet-stream;
    }

chrome_503.mp4

[apecity]

I should add: We deal with attachments all the time and never had an issue like this come up until we updated to 1.8.101. The issue doesn't seem to affect PDF files, which continue to work normally. Tried clearing caches, different computers, etc., but problem is the same.

[freescout-helpdesk]

Try to remove the new block from nginx and check.

[freescout-helpdesk]

Also are you using Apache in addition to nginx? Or just nginx?

[freescout-helpdesk]

Are you using CloudFlare? #3431 (comment)

[apecity]

Removing that block from the nginx config fixed the issue. .xlsx file downloads working again.

We're only using nginx.

We are not using Cloudflare.

[apecity]

Apache is not running on our system.

[freescout-helpdesk]

Can you share your nginx config when the new block is added.

[apecity]

Our nginx config file is here.
I've left the new location section for 1.8.101 commented out, as enabling it appears to cause the .xlsx attachment problem.

server {

    server_name service.fr8.vu;

    root /var/www/html/public;

    index index.php index.html index.htm;

    error_log /var/www/html/storage/logs/web-server.log;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/run/php/php8.1-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include fastcgi_params;
    }
    # Uncomment this location if you want to improve attachments downloading speed.
    # Also make sure to set APP_DOWNLOAD_ATTACHMENTS_VIA=nginx in the .env file.
    #location ^~ /storage/app/attachment/ {
    #    internal;
    #    alias /var/www/html/storage/app/attachment/;
    #}
    # This is the location section we added with the 1.8.101 update.  
    #    location ~* ^/storage/.*\.((?!(jpg|jpeg|jfif|pjpeg|pjp|apng|bmp|gif|ico|cur|png|tif|tiff|webp|pdf|txt|diff|patch|json|mp3|wav|ogg|wma)).)*$ {
    #        add_header Content-disposition "attachment; filename=$2";
    #        default_type application/octet-stream;
    #    }
    location ~* ^/storage/attachment/ {
        expires 1M;
        access_log off;
        try_files $uri $uri/ /index.php?$query_string;
    }
    location ~* ^/(?:css|js)/.*\.(?:css|js)$ {
        expires 2d;
        access_log off;
        add_header Cache-Control "public, must-revalidate";
    }
    location ~* ^/(?:css|fonts|img|installer|js|modules|[^\\\]+\..*)$ {
        expires 1M;
        access_log off;
        add_header Cache-Control "public";
    }
    location ~ /\. {
        deny  all;
    }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/service.fr8.vu/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/service.fr8.vu/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


}
server {
    if ($host = service.fr8.vu) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;

    server_name service.fr8.vu;
    return 404; # managed by Certbot
}

[freescout-helpdesk]

New block is in the wrong place. This block of code has to be inserted in the very specific place in the nginx config: nginx configuration

[HPdeVries]

I have the same issue. Taking a third look at the example configuration for nginx solved it. I also had the added config in the wrong place.

[freescout-helpdesk]

Also notice that the latest version of the block has filename=$2 instead of filename=$1: https://github.com/freescout-helpdesk/freescout/wiki/Installation-Guide#61-nginx

[apecity]

Thanks everyone for the help. I didn't know about the nginx location clauses ordering policy.

[apecity]

SInce this one was caused by my own error (didn't put the nginx clause in the right place) I will close this ticket. Thanks again to the Freescout team.