Probably not the problem the OP had, but I had this issue while trying to build my container running inside Windows Subsystem for Linux (WSL) (Debian WSL2), just after having freshly installed Docker Compose and all I had to do was close the (Debian) terminal and reopen it and my issue was solved.

I had the same issue and all I had to do was to capitalize the Docker configuration filename:

dockerfile > didn't work

Dockerfile > did work

If you are using Docker Desktop, restarting Docker worked for me. Troubleshoot → Restart

In my case I was trying to copy over folder wp-content from my current directory, inside the Docker image I was building. Like so:

FROM wordpress:latest

# Copy wp-content
COPY ./wp-content/ ./var/www/html/wp-content/

However, I noticed that I had a .dockerignore file, which explicitly was told to ignore wp-content.

When I removed wp-content/ from .dockerignore it worked fine.

In my case, I had an extra space after "." in the context option:

docker build -t myapp .[EXTRA_SPACE_HERE]

In my case, I had two problems:

1. I missed the . in the end of the command that gives the context option, and
2. I have a ".txt" extension in the file name of the Dockerfile.

After these two adjustments, all worked as expected.

Make sure your .dockerignore doesn't match your file.

A pattern sometimes used with .dockerignore is to add a wildcard to it and exclude the specifically expected file to the context with !filename syntax. EG:

*
!Cargo.toml
!Cargo.lock
!src
!setup.py
!README.md
!project
!requirements
__pycache__

If you later try to use a file in Dockerfile it will match the wildcard and not be present in the context. Add an exception to the new file or remove the wildcard to fix this.

If you are using Windows Subsystem for Linux (WSL), check if Docker is running before you launch the window. If you have started Docker after starting the window. Then Just restart your terminal. And it should work if your file is correct.

In my case

failed to solve with frontend dockerfile.v0: failed to create LLB definition: no build stage in current context

was caused by setting ENV before FROM. Probably this is not allowed for some Dockerfile instructions. After moving ENV right after FROM the error is gone.

Sometimes this kind of error comes from a stupid syntax error... In my case I modified a Dockerfile and removed some environment variables, but forgot to take off the backslash from the last line...

    WORDPRESS_HTTPS_PORT="8443" \
    WORDPRESS_HTTP_PORT="8080" \
    WORDPRESS_SKIP_INSTALL="yes" \ <-- to be removed

EXPOSE 8080 8443
USER 0

I don't remember where exactly I read this, but if you are using WSL2 and receive that error, then delete the Docker configuration file in your WSL2 home folder and try to rebuild your image.

That is if you have already checked your file names and reconfirmed that everything is named correctly (Dockerfile, .dockerignore, etc.)

WSL2 Ubuntu:

rm ~/.docker/config.json

I had experienced this issue after upgrading to the latest Docker Desktop version on Mac. Solved with the comment on this issue.

Solution: Don't use buildkit and it works for me.

export DOCKER_BUILDKIT=0
export COMPOSE_DOCKER_CLI_BUILD=0

Had a typo,

FROM apline:3.7 instead of FROM alpine:3.7

I got this issue when I'd run out of disk space, presumably exacerbated by the numerous image layer caches building up as I teased and tweaked my Dockerfile.

If you are seeing this issue it is not actually the real issue. The actual issue is nested in the error logs somewhere. To see the actual issue you need to run your build command like this:

DOCKER_BUILDKIT=0  docker build .

Notice the DOCKER_BUILDKIT=0. That will make the build kit not hide the nested error. From there you should be able to google the correct solution.

This will also make the build look different in command line, but don't worry about that. Just look for the error.

Chiming in with another possibility that happened to me: If you're using build stages, make sure that you have the right stage names throughout.

I had a stage defined with

FROM zzz AS development

that was later used for another stage

FROM development AS yyy

On a whim I changed development to dev, but only in the first instance. So the latter one was still FROM development while the former was AS dev.

Odd how arcane the error message is for a such a minor mistake... You'd think they could just have the error message say "couldn't find development" or something.

I had to set "credsStore": "" in my ~/.docker/config.json .... It was previously set to credentials.exe.

In WSL2 ddev start fails at docker-credential-desktop.exe, "error listing credentials" #2342

Specify the proxy server by setting the HTTP_PROYY and HTTP_PROXYS environment variables.

Example:

http_proxy=http://username:password@proxy.example.com:8080
https_proxy=http://username:password@proxy.example.com:8080

Disable the macOS v11 (Big Sur) virtualization framework:

Make sure that you are using the same platforms, e.g. if you build the first image (my-custom-service) with

FROM --platform=linux/amd64 node:14

then you need to add the --platform to other Dockerfiles that use the baseimage of the first:

FROM --platform=linux/amd64 my-custom-service

I ran into this problem using WSL2 Ubuntu, and I fixed it by changing the permissions of the Dockerfile.

When I set up WSL2 on my computer I copied some of my files (including the Dockerfile) directly from Windows into the Ubuntu root folder, which apparently results in files with blank permissions:

---------- 1 user user 10M Jan 1 00:00 Dockerfile

To fix it I ran chmod 644 Dockerfile:

-rw-r--r-- 1 user user 10M Jan 1 00:00 Dockerfile

And after that Docker was able to build the image without any further issue.

As far as I can see, this error can have many reasons.

In my case, there were two errors: (1) in the Dockerfile: the # syntax = ***** line was incorrectly spelled out and (2) in file docker_compose.yaml, the web / build: * line was pointing to the wrong directory.

I was helped by reading the Dockerfile documentation and taking a break to regain attention.

For me the following was the error:

failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to do request: Head https://registry-1.docker.io/v2/library/postgres/manifests/13-alpine: net/http: TLS handshake timeout

I am using WSL2 in Windows 10 and Docker Desktop and I got this issue after updating the Docker Desktop to version 3.5.

I fixed the issue by enabling the WSL integration with additional distributions.

To enable it:

Open Docker Desktop in Windows and go to settings → Resources → WSL Integration → Enable integration with additional distributions and enable it for the Ubuntu application that you installed.

In my case, I had to uninstall Astrill VPN.

I faced the issue due to VPN connectivity.

All I had to do was set a manual proxy in the Docker Desktop PROXIES section:

I've had this issue/error before when I had a script that I used to build multiple Dockerfiles and where one of the Dockerfiles was commented out. Once I uncommented the Dockerfile and run the script again it worked fine for me.

I had the same error, but by moving the Dockerfile out of the sub-folder and into the root folder of my application. It fixed the error message.

I have the same issue.

Docker filename:

• DockerFile - error
• dockerFile - error
• Dockerfile - work!

You need only one capitalized character.

If you use Docker for Windows, then be sure that the Docker engine is set to the mode matching the image you want to build (Windows / Linux).

If you use Docker for Windows you need to disable buildkit. It works for me.

Set buildkit option to false.

{
  "builder": {
    "gc": {
      "defaultKeepStorage": "20GB",
      "enabled": true
    }
  },
  "experimental": false,
  "features": {
    "buildkit": false
  }
}

If you are using Docker Desktop for Mac or Windows, you might have to also disable it in your 'Docker Engine' JSON configuration.

Docker Desktop → Settings → Docker Engine → change the "features": { buildkit: true} to "features": { buildkit: false}.

In case your docker file is in a different path with different name than Dockerfile you can run

docker build -t build_tag_name -f './path/to/dockerfile/exampledockerfile' .

I had the same issue while building a Docker image through Visual Studio 2019. My Docker file had a name like Dockerfile.

Dockerfile > didn't work

dockerfile > did work

In case you have a similar project structure

├── docker                   
│   │
│   ├── app
│   │   └── Dockerfile
│   └── mlflow  
│       └── Dockerfile
│
└── docker-compose.yml

you might be missing to specify the build: context in the docker-compose.yml

version: '3'

services:

  mlflow:
    build: 
      context: ./
      dockerfile: ./docker/mlflow/Dockerfile
    container_name: ml_app_mlflow
    volumes:
      - ./db:/db
    ports:
      - 5000:5000

In case you previously executed docker buildx install, your docker command is aliased to docker buildx, which is based on Docker Buildkit, which is currently not supported (sadly) on Windows.

To remove the alias, execute the following command:

docker buildx uninstall

I hope that will save time to people like me, who forgot about this alias

For me, I found that I was trying to build from the wrong directory.

In my case, this was because of the under-expressed use cases from documents. almost all examples tell you to use . and Dockerfile (capital D) but mostly does not tell explicitly how to customize.

docker image build --tag any_image_tag --file any_file_name path_to_your_context_folder

This one is better in my opinion, and I hope will help those coming here. any_file_name is really any file name with build instructions in it, "dockerfile" in it is not needed but helps to identify and give full path if it differs from context folder. path_to_your_context_folder is basically where your work resides, such as a web app.

for example, the following is my current test in windows where COPY . /app uses context folder as the .:

docker image build --tag nested_image --file C:\WorkSpace\myapp\dockerfiles\any_file_name C:\WorkSpace\myapp\contextfiles\

PS: The topic really has interesting answers to the same problem but by lots of exotic causes. mine is just a side note to a hidden-in-plain-sight problem.