Uploads larger than 32KB fail with 500 — client_body_temp not writable by nginx worker

[stanpete78]

Hi,

I ran into an issue that's a bit tricky to spot, so I wanted to write it up in case others hit the same thing.

When a client uploads anything bigger than ~32KB, nginx wants to buffer the body to /usr/local/nginx/client_body_temp/. On my setup that fails with a permission error — the directory is owned by root but the nginx worker runs as npm. The client just sees a generic 500 Internal Server Error, and nothing reaches the upstream container, which makes it look like the backend is broken when it actually isn't.

What I see inside the container:

$ docker exec NPMplus ls -la /usr/local/nginx/ | grep temp
drwx------ 1 root users   0 May 24 10:41 client_body_temp
drwx------ 1 root users  18 May 13 08:28 proxy_temp
...

$ docker exec NPMplus id npm
uid=99(npm) gid=100(users)

And the matching nginx error:

[crit] open() "/usr/local/nginx/client_body_temp/0000000074" failed (13: Permission denied)
       client: X.X.X.X, request: "POST /api/import HTTP/2.0"

Interestingly, proxy_temp has the same wrong owner at the top level but works fine, because nginx writes into hash subdirectories there (and those get created lazily with the right owner). client_body_temp writes files into the top-level directly, so it actually hits the permission.

In my case it took a while to track down because most apps send small requests, so the buggy code path basically never gets exercised. The trigger here was an ESP32 GPS logger uploading 100+ KB GPX files.

Workarounds I tried:

• client_body_buffer_size 4m; in custom_nginx/server_http.conf — keeps reasonably sized bodies in RAM. That's what I'm running with now.
• docker exec NPMplus chown npm:users /usr/local/nginx/client_body_temp — works until the next restart.

A proper fix would probably be a chown in the entrypoint or image build, ideally for the other temp dirs too (fastcgi_temp etc.).

Environment: zoeyvid/npmplus:latest (built 2026-04-21), Unraid 7. The temp directories live in the container filesystem itself, not a bind mount, so this should look the same on any host. CrowdSec AppSec is off, so it's not related to #2582.

Happy to provide more info if it helps.

[Zoey2936]

can you please share your compose.yaml?

[stanpete78]

There's no compose file — the container was started via Unraid's docker template. Equivalent of what's running, with paths anonymized:

services:
  npmplus:
    image: zoeyvid/npmplus:latest
    network_mode: "br0"           # macvlan
    restart: unless-stopped
    environment:
      - PUID=99
      - PGID=100
      - TZ=Europe/Berlin
      - GOA=false
      - ACME_PROFILE=none
    volumes:
      - <appdata>/npmplus/data:/data
      - <appdata>/npmplus/www:/var/www

Nothing special — PUID=99 / PGID=100 are the Unraid defaults. No custom user, no cap_add, no security_opt.

Worth noting: /usr/local/nginx/client_body_temp lives in the container filesystem, not in either of the bind mounts, so PUID/PGID and host volume permissions shouldn't affect it. The directory is created with root:users:0700 inside the image itself.

[Zoey2936]

https://github.com/ZoeyVid/NPMplus/blob/develop/rootfs/usr/local/bin/start.sh#L525-L531 it should be correctly owned

[stanpete78]

Quick follow-up: you were right that start.sh handles this — the misalignment was on my end.

I recreated the container from scratch (removed it, re-installed from the same template), and the temp directories now look exactly as expected:

$ docker exec NPMplus ls -la /usr/local/nginx/ | grep temp
drwx------ 1 npm users 0 May 25 18:52 client_body_temp
drwx------ 1 npm users 0 May 25 18:52 fastcgi_temp
drwx------ 1 npm users 0 May 25 18:52 proxy_temp
drwx------ 1 npm users 0 May 25 18:52 scgi_temp
drwx------ 1 npm users 0 May 25 18:52 uwsgi_temp

Owned by npm:users, all created during startup, uploads work without client_body_buffer_size workarounds.

Best guess at what was different on the original container: it had been running for a long time and at some point lost its net.unraid.docker.managed label (unrelated Unraid plumbing thing). When that happens, Unraid's UI loses the "Edit" button, and any updates to the image have to go through a manual docker pull + docker run flow that bypasses the template — which probably skipped or interrupted parts of start.sh on one of the recreates. A clean recreate from the template fixed it cleanly.

So nothing for you to fix here — the start.sh logic is sound, it just needed to actually run end-to-end. Thanks for taking the time to look.