HansAlbers

Then that means the attachment upload failed or something is going on with the user session. Curious, do you have the setting that requires users to be logged in in order to view attachments?

Cheers.

HansAlbers

Hmmm, that is quite the conundrum. When you upload the attachment you should see a POST request. This POST request should return a response like {"id":123} on success or an error/etc. on failure. In your case, what do you see?

Cheers.

HansAlbers

You are supposed to click on the Response tab within the Network tab after clicking on the POST request.

Cheers.

HansAlbers

That simply means it’s expecting the ID response (which is JSON format) but it’s getting HTML in the response instead. What else is different between the setups? Also, PHP 8.3 is not fully supported yet so that install will run into some issues at some point.

Cheers.

HansAlbers

You can try going here and adding some error_log() lines at different points to see where it's failing.

Cheers.

ramrajone

That's what I was wondering but then I thought: "Why would it work for Agents and not Users if it was the filesystem?"

Cheers.

HansAlbers

Ah, I went back and realized you are using NGINX; don't know how I missed that the first time. Compare your NGINX config with the below and see if you are missing anything. If so update yours, run the NGINX test command on the config file to make sure nothing will break, reload NGINX, and retest.

user  nginx;
worker_processes 1;

events {
    worker_connections  1024;
}

http {
    include         mime.types;
    default_type    application/octet-stream;
    sendfile        on;
    charset         utf-8;
    gzip            on;
    gzip_types      text/plain application/xml text/javascript;
    gzip_min_length 1000;

    index index.php index.html index.htm;

    # Rewrite all requests from HTTP to HTTPS
    server {
        listen 80;
        server_name tickets.mydomain.com;
        rewrite ^ https://tickets.mydomain.com permanent;
    }

    server {
        listen 443;
        server_name tickets.mydomain.com;
        ssl on;
        ssl_certificate /etc/nginx/certs/cert.pem;
        ssl_certificate_key /etc/nginx/certs/cert.key;

        keepalive_timeout 70;

        root /var/www/osticket;

        set $path_info "";

        location ~ /include {
            deny all;
            return 403;
        }

        if ($request_uri ~ "^/api(/[^\?]+)") {
            set $path_info $1;
        }

        location ~ ^/api/(?:tickets|tasks).*$ {
            try_files $uri $uri/ /api/http.php?$query_string;
        }

        if ($request_uri ~ "^/scp/.*\.php(/[^\?]+)") {
            set $path_info $1;
        }

        if ($request_uri ~ "^/.*\.php(/[^\?]+)") {
            set $path_info $1;
        }

        location ~ ^/scp/ajax.php/.*$ {
            try_files $uri $uri/ /scp/ajax.php?$query_string;
        }

        location ~ ^/ajax.php/.*$ {
            try_files $uri $uri/ /ajax.php?$query_string;
        }

        location / {
            try_files $uri $uri/ index.php;
        }

        location ~ \.php$ {
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            include        fastcgi_params;
            fastcgi_param  PATH_INFO        $path_info;
            fastcgi_pass   127.0.0.1:8888;
        }
    }
}

Cheers.

HansAlbers

The problem is NGINX is not supported out of the box. Go read the osTicket requirements to see what I'm saying. NGINX is supported just requires its own special config (additional setup). Litespeed is a drop-in replacement for Apache which is fully supported out of the box (ie. no custom config needed). We ship with the relevant .htaccess file and web.config files for Apache and IIS respectively. However, NGINX never worked like that as they saw it as tacky and security issue prone. So they make people add it the "right way" which means we can't ship with our own files that just "work out of the box".

Cheers.