Skip to content

Docker Build “Permission Denied”? Here’s the Fix

4 min read

If you’ve ever tried to build a Docker image and were met with the frustrating error:

bash

permission denied while trying to connect to the Docker daemon socket

—or something like:

bash

EACCES: permission denied, mkdir '/app/node_modules'

You’re not alone. Many developers run into this issue, especially when starting out with Docker or moving projects across different environments. Fortunately, the fix is usually straightforward once you understand what’s causing the problem.

In this post, we’ll break down the most common causes of the Docker “permission denied” error during build, and give you step-by-step solutions.


What Causes the Docker Build “Permission Denied” Error?

Docker needs elevated permissions to perform certain operations like accessing the Docker daemon or writing to directories inside the container. Common reasons for permission issues include:

  • Running Docker without sudo
  • Incorrect ownership of files or folders
  • File system restrictions (especially with mounted volumes)
  • Trying to access restricted directories
  • SELinux or AppArmor blocking file operations

Let’s fix these one by one.


🔧 Fix 1: Run Docker With Sudo (or Add User to Docker Group)

If you’re on Linux and get this:

bash

Got permission denied while trying to connect to the Docker daemon socket

It usually means your user doesn’t have permission to run Docker commands.

➤ Solution A: Use sudo
sudo docker build -t your-image-name .

But typing sudo every time is annoying and can cause issues with some scripts or CI pipelines.

➤ Solution B: Add your user to the docker group

bash

sudo usermod -aG docker $USER

Then log out and log back in (or restart your system).

You can verify with:

bash

docker run hello-world

If it runs without sudo, you’re good to go.


🔧 Fix 2: File System Permissions (Especially with Node.js, Python, etc.)

Sometimes during build, you may see:

bash

EACCES: permission denied, mkdir '/app/node_modules'

This typically happens when your Dockerfile is trying to write into a folder that has restrictive permissions.

➤ Solution: Set Correct Ownership or Permissions

In your Dockerfile, ensure you’re setting proper ownership:

Docker

# Example for Node.js
RUN mkdir -p /app && chown -R node:node /app
USER node

Or for Python-based apps:

Docker

RUN mkdir -p /usr/src/app && chmod -R 755 /usr/src/app

Alternatively, you can adjust permissions locally:

bash

sudo chown -R $USER:$USER your-project-folder

Avoid using chmod 777 unless you’re in a hurry for a dev-only container—it’s a bad practice in production.


🔧 Fix 3: Docker Volumes and Bind Mounts

Mounting a host directory with incorrect permissions is a common cause of permission errors inside containers.

For example:

bash

docker run -v $(pwd):/app your-image

If the /app directory expects to be written to, but your local folder is owned by root or has strict permissions, Docker will throw permission errors.

➤ Solution:

Make sure your local directory has the right ownership and permissions:

bash

sudo chown -R $USER:$USER .
chmod -R u+rw .

Also, avoid mounting sensitive directories unless absolutely needed.


🔧 Fix 4: SELinux or AppArmor Restrictions (Advanced)

On some Linux distros (especially Fedora or CentOS), SELinux might block Docker containers from writing to mounted volumes.

To verify if this is the issue, check system logs:

bash

dmesg | grep denied

Or try running with the :Z or :z mount option:

docker run -v $(pwd):/app:Z your-image

This tells SELinux to relabel the volume appropriately.


🔧 Fix 5: Multi-Stage Builds and Missing User Context

If you’re using multi-stage Docker builds, remember that user permissions don’t carry over by default.

Example:

Docker

FROM node:18 as builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html

Make sure the final image has permission to read from the copied folders.

You can force ownership using:

Docker

COPY --chown=nginx:nginx --from=builder /app/build /usr/share/nginx/html

Best Practices to Avoid Permission Issues
  1. Use non-root users inside Docker whenever possible.
  2. Set folder permissions explicitly in your Dockerfile.
  3. Avoid chmod 777 — use precise permissions like 755 or 700.
  4. Mount volumes carefully and ensure your host system’s file ownership is compatible.
  5. Use linter tools like hadolint to catch Dockerfile issues early.


🚀 Conclusion

The “permission denied” error when building Docker images can be frustrating, but it’s usually caused by one of a few common issues: missing group access, wrong ownership, or restrictive file system settings. With the fixes above, you should be able to identify and resolve the problem quickly.

By following best practices—like using the Docker group, managing file permissions carefully, and avoiding overly permissive access—you can prevent these headaches in future projects.