I am trying to build a Docker image for my Node.js application, but the build keeps failing at the COPY step. I am using COPY . /app, but it returns an error saying "file not found in build context." The files are definitely in the same folder as my Dockerfile. Is there a specific rule about how the build context works, or could my .dockerignore file be causing the command to skip the files I actually need for the image?
3 answers
The most common reason for a COPY failure is misunderstanding the Docker "build context." When you run docker build ., the dot represents the context. Docker can only "see" files inside that specific directory. If your Dockerfile is in a subfolder but you're trying to copy files from a parent folder, it will fail because the builder doesn't have access to anything outside the context. Another major culprit is the .dockerignore file; if you have a wildcard entry there that accidentally matches your source files, Docker will exclude them from the context sent to the daemon. Check your file paths relative to where you are running the build command, not relative to where the Dockerfile is located.
Sarah's point about the context is vital, but have you checked if you are using a multi-stage build where you might be trying to COPY --from=stage a file that hasn't actually been created in that previous layer?
Sometimes it's just a simple permission issue on Linux. Ensure the Docker daemon has read access to the files in your directory, otherwise, it won't be able to package them into the context.
I agree with Kimberly. I’ve seen cases where files were owned by root and the user running the build couldn't access them. Running a quick chmod or chown on your project folder can occasionally solve the "not found" mystery immediately.
Marcus, that’s a sharp observation for modern Docker workflows. In multi-stage builds, if the previous stage fails or if you have the wrong path for the output artifact, the subsequent stage's COPY will definitely fail with a "no such file" error. I always recommend adding a RUN ls -la in the previous stage just to debug and verify that the file actually exists exactly where you think it does before you try to pull it into your final production image.