Fix 'failed to read dockerfile: open Dockerfile: no such file or directory' When Building Docker Image

TL;DR

Docker can't find your Dockerfile because it's not in the build context directory you gave it. Either run docker build from the directory that contains your Dockerfile, or point to the file explicitly with -f:

# Option 1: move into the directory first
cd /path/to/your/project
docker build -t myapp .

# Option 2: keep your current directory, specify the file path
docker build -f /path/to/your/project/Dockerfile -t myapp .

Root Cause

Every docker build command takes a build context — the directory Docker packages up and ships to the daemon. By default (when you pass .), that's your current working directory. The daemon then looks for Dockerfile inside that directory.

The full error message looks like:

failed to solve: failed to read dockerfile: open Dockerfile: no such file or directory

A handful of things trigger it:

You ran docker build . from the wrong directory — the Dockerfile lives somewhere else entirely.
The file has a different name: dockerfile, Dockerfile.dev, DockerFile — Linux filesystems are case-sensitive, so these won't match.
Someone accidentally added Dockerfile to .dockerignore.
The build context path you specified doesn't contain any Dockerfile.
In CI/CD, the pipeline's working directory isn't what the config assumes.

Step-by-Step Fix

Step 1: Confirm where your Dockerfile actually is

# Linux — case-sensitive search
find . -name 'Dockerfile' -type f

# macOS — case-insensitive filesystem, but still worth a sanity check
find . -iname 'dockerfile' -type f

No results? The file doesn't exist yet — create it. Found it at an unexpected path? Either move it, or use -f to point Docker at the right location.

Step 2: Run docker build from the correct directory

The classic mistake: running docker build . from a parent or sibling directory. That . means "use my current directory as the build context", and Docker expects Dockerfile to be inside it.

# Wrong — you're in /home/user but Dockerfile is in /home/user/myapp
docker build -t myapp .

# Right — cd first, then build
cd myapp
docker build -t myapp .

One cd away from the fix.

Step 3: Use -f for non-standard names or locations

Projects with multiple environments often keep separate Dockerfiles — one per stage. Specify the path explicitly rather than renaming files around:

# File has a non-default name
docker build -f Dockerfile.prod -t myapp .

# File lives in a subdirectory
docker build -f docker/Dockerfile -t myapp .

# File is outside the build context (less common but valid)
docker build -f ../Dockerfile -t myapp .

Important: -f and the build context (the last argument) are independent. The context controls which files the daemon can access during the build. The -f flag only determines which file gets used as the Dockerfile. Mixing them up is a common source of confusion.

Step 4: Check .dockerignore

Open .dockerignore and look for any line that matches your Dockerfile:

cat .dockerignore

If Dockerfile is listed there, remove it. Docker usually special-cases the Dockerfile and ignores that entry — but certain BuildKit configurations don't follow that convention, leading to the exact error you're seeing.

Step 5: Fix the working directory in CI/CD

GitHub Actions, GitLab CI, and Jenkins each have their own idea of what the working directory should be. Don't assume — be explicit:

# GitHub Actions: set working-directory per step
- name: Build Docker image
  run: docker build -t myapp .
  working-directory: ./myapp

# Or use an absolute path so there's no ambiguity
- name: Build Docker image
  run: docker build -f ${{ github.workspace }}/myapp/Dockerfile -t myapp ${{ github.workspace }}/myapp

# GitLab CI: cd explicitly before building
build:
  script:
    - cd myapp && docker build -t myapp .

Step 6: Docker Compose — verify the build context in compose.yaml

When the error comes through docker compose build, the context comes from your compose file, not the shell's current directory:

# compose.yaml
services:
  app:
    build:
      context: ./myapp        # this directory must contain Dockerfile
      dockerfile: Dockerfile  # optional — 'Dockerfile' is the default

Double-check that context points at the directory that actually holds your Dockerfile, not a parent or sibling.

Verification

Rerun the build. A working command streams layer output immediately:

docker build -t myapp .

# Expected output (BuildKit):
[+] Building 3.2s (10/10) FINISHED
 => [internal] load build definition from Dockerfile          0.0s
 => [internal] load .dockerignore                             0.0s
 => [internal] load metadata for docker.io/library/node:20    1.4s
 ...

Once you see [internal] load build definition from Dockerfile without an error on the next line, you're good — Docker found the file.

Quick Reference: Common Scenarios

Wrong directory → cd into the directory that contains Dockerfile, then build.
Non-standard filename → docker build -f Dockerfile.prod .
Monorepo / nested structure → docker build -f services/api/Dockerfile . from the repo root, or cd services/api && docker build .
CI pipeline → set working-directory explicitly, or use absolute paths with -f.
Docker Compose → verify the context: path in compose.yaml.