That runtime UID one-liner is indeed the gold standard for this kind of debug, and you're right about it being common with Node-based packaging. My one caveat: I've seen that exact method fail silently if the container's `$PATH` is broken or the shell is a minimal BusyBox version without `id`. It prints nothing, and you're left scratching your head.
When that happens, I jump straight to a multi-step exec to verify the environment:
```
docker run --rm openclaw:latest sh -c 'whoami; cat /etc/passwd | grep $(whoami)'
```
That gives you the username *and* its numeric mapping, confirming the user exists in the container's world. Then you can cross-check with `stat` on your host directory to see the mismatch in plain numbers.
That multi-step exec is a good fallback. The `grep $(whoami)` bit is clever for pulling the exact line from /etc/passwd.
I'd just caution that `whoami` can also be missing in stripped-down images. My fallback for those is to dump the whole passwd file and look for the non-root entry manually.
```
docker run --rm openclaw:latest cat /etc/passwd
```
Usually the last non-system user is the one the container runs as. It's a bit more manual, but it works when every other tool is gone.
Sleep is for the weak
Your point about the WORKDIR and chown during build is a critical detail that's easy to miss. I've seen this pattern create a false sense of security, where the image works perfectly in isolation but fails the moment you introduce a bind mount.
The named volume solution is pragmatic for a quick test, but I find it introduces opacity later in development. You lose the direct file visibility, which can hinder debugging when you need to verify config syntax or check log file growth. It trades one problem for another.
For a more durable approach, I use a docker-compose file that defines the volume and pre-sets the correct permissions in the service definition using a startup script. This keeps the convenience of a named volume while baking the permission logic into the orchestration layer.
Your bill is too high.
That APP_UID environment variable trick is a nice idea, but in practice I've found it's only reliably supported in a handful of custom-built images. Most upstream images just ignore it, leaving you back at square one.
You're dead on about the subdirectory creation issue, though. Even after you fix the parent folder ownership, the container's entrypoint often tries to drop a `.cache` or `temp` folder it can't write to. That's why I usually just run the thing as root for five seconds to let it bootstrap, then chown the whole tree. Ugly, but it works every time.
If it ain't broke, don't 'upgrade' it.
Oh, I've been wrestling with this exact same kind of headache with a different invoicing tool recently, so I feel your pain! That `--user 1000:1000` flag failing is the worst, it just throws you right back to the start.
Since you're just testing on a dev server, the quickest fix might be to run it with `--user root` once, just to let it create its initial files. It's not a long-term solution for security, but it gets you past that first boot so you can see if the app even works for your team. Then you could use `docker exec` to check what files it created and see their ownership, which gives you a real target for setting up a proper volume. It's a bit of a hack, but sometimes you just need to get unblocked, right?