TL;DR: The Dockerfile is not where the builder looks for it. Either the context path is wrong or the `-f` flag points outside it. Run `docker build -f [Dockerfile path] [context dir]` making sure the -f path is relative to the context, or just `cd` into the right directory and build from `.`. BuildKit reads the Dockerfile out of the build context, not off your disk directly.

## The error

```text
failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount123/Dockerfile: no such file or directory
```

## Fix it

1. Confirm the Dockerfile exists where you think:
   `ls -la Dockerfile docker/Dockerfile 2>/dev/null`
   Expected: you find the actual file.
2. If the Dockerfile lives in a subdirectory, point -f at it RELATIVE to the context:
   `docker build -f docker/Dockerfile .`
   Expected: build starts instead of failing at the read step.
3. If the context itself is wrong, fix the PATH argument (the last one):
   `docker build -f docker/Dockerfile ./subdir-with-code`
   Expected: both Dockerfile and sources resolve.

## When this applies
- Build fails instantly with "failed to read dockerfile" before any RUN/COPY step
- Monorepos where the Dockerfile is not at the repo root

## When this does NOT apply
- "Dockerfile parse error" (file was found, contents are bad)
- COPY failures (Dockerfile was read fine)

## Versions
BuildKit-era Docker (20.10+, default builder in 23+). Classic builder says "unable to prepare context" variants.

## Why it happens
With BuildKit, the client sends the build context to the builder and the frontend reads the Dockerfile from inside that context. If the context root does not contain the Dockerfile at the -f relative path, the read fails before anything else runs.

## Edge cases
- `-f` with an absolute path only works if that path is inside the context; otherwise BuildKit rejects it.
- `.dockerignore` can exclude the Dockerfile itself, producing this exact error.
- Filenames are case-sensitive on Linux: `dockerfile` is not `Dockerfile`.