Skip to main content
Question

*.pkg/index.bom is not a directory

  • February 17, 2026
  • 2 replies
  • 52 views
D

Hi Jamf Folks,

I use nginx file distrubtion server. It works, but I have errors in the nginx log everytime I install something via Self Service +
```
2026/02/17 12:54:16 [error] 13387#0: *1 open() "/<pathToPkg>/Package.pkg/index.bom" failed (20: Not a directory), client: <ip-addresse>, server: webserver.de, request: "GET /<pathToPkg>/Package.pkg/index.bom HTTP/1.1", host: "webserver.de"
```

When I download it via webbrowser or wget, I do not get an error.
here is my nginx.conf
```

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include mime.types;
    default_type application/octet-stream;

    server {
        listen 443 ssl;
        http2 on;
        server_name webserver.de;

        ssl_certificate     fullchain.pem;
        ssl_certificate_key privkey.pem;

        location /Packages/ {
            alias /<pathToPkg>/Packages/;
            auth_basic "Downloads";
            auth_basic_user_file /<pathto>/htpasswd;
            types {
                application/octet-stream pkg;
            }
            limit_except GET HEAD { deny all; }
        }
        error_page 400 403 405 408 410 413 414 415 429 500 501 502 503 504
            =302 https://fehlerwebsite.de;
    }
}
```
Maybe someone has a idea to fix it 

    2 replies

    S
    Forum|alt.badge.img+3
    • schiemsk
    • New Contributor
    • March 9, 2026

    Hi,

    I think this is an empirical, client-side method for determining the package type.
    A folder can very well be named something like "something.pkg/", so the jamf client on the endpoint makes a request to "./index.bom" to determine the action to take (download the file "something.pkg" or browse to a folder with that name).
    Before seeing this error, I didn't even think it was possible: I've always worked with flat packages (pkg and dmg).

    We very recently enabled an HTTP(s)-DP (with authentication) to open our package repository to mobile workstations without requiring a specific network location (since mounting the file server obviously can't be done outside of a trusted network).

    Since enabling HTTP(s)-DP, as the primary DP, I consistently see double GET requests in the Apache logs (the first with a 404 error, the second with an HTTP 200 success). Whether through automatic deployment or self-service installation(+)

    For example:
    http-dp.dom.tld 10.0.0.57 - XXXXX [09/Mar/2026:11:42:29 +0100] "GET /DistriPoint/Packages/PRN-Toshiba-drvs_7.x.pkg/index.bom HTTP/1.1" 404 236

    http-dp.dom.tld 10.0.0.57 - XXXXX [09/Mar/2026:11:42:30 +0100] "GET /DistriPoint/Packages/PRN-Toshiba-drvs_7.x.pkg HTTP/1.1" 200 5105387

    sorry, tag mistake

    While browsing the community forum, I came across older, unanswered posts addressing this issue… and we don't like having 404 errors in the logs for legitimate actions without being able to fix them, isn’t it ?
    I'm quite surprised (if my deduction is correct) that this somewhat dirty and noisy method hasn't been improved. There might not be a simple or less noisy solution (a single 404 hit might be preferable to more "clean" requests), but it should at least be documented.


    Regards.

     

    S
    Forum|alt.badge.img+3
    • schiemsk
    • New Contributor
    • March 9, 2026


            error_page 400 403 405 408 410 413 414 415 429 500 501 502 503 504
                =302 https://fehlerwebsite.de;
        }
    }
    ```
    Maybe someone has a idea to fix it 

    In your case, I think your problem stems from the fact that you're handling 404 errors in a specific way (redirecting them with a 302), which is causing the Self Service to fail.

    Since the Self Service doesn't receive a 404 error (but a 302), it doesn't attempt a direct download via a second request, as in my example shown above.

    Terms & ConditionsCookie settingsAccessibility statement