Introduction

When a bind-mounted host directory is not writable from a container on Ubuntu, the problem is usually file ownership or permissions, not Docker itself. The container process runs as some user and group ID, and that identity must have write access to the mounted path on the host filesystem. Solving the issue means aligning container user IDs, host directory permissions, and sometimes SELinux or rootless-container behavior depending on the environment.

Understand the Permission Boundary

A bind mount such as this:

docker run --rm -it -v "$PWD/data:/app/data" ubuntu:24.04 bash

shares the real host directory with the container. Docker does not magically normalize file permissions. If the process inside the container writes as UID 1000 but the host directory belongs to UID 0 with restrictive mode bits, the write fails.

That is why "the volume is mounted" and "the volume is writable" are separate questions.

Reproduce and Inspect the IDs

A minimal debug session is often enough to show the mismatch.

1mkdir -p data
2ls -ld data
3
4docker run --rm -it -v "$PWD/data:/app/data" ubuntu:24.04 bash -lc 'id && touch /app/data/test.txt'

If touch fails, compare the container user identity with the host directory ownership.

On the host:

ls -ln data

Numeric IDs matter more than names because the kernel permission check is based on UID and GID.

Fix by Matching the Container User

A common solution is to run the container as the same UID and GID as the host user.

1docker run --rm -it \
2  --user "$(id -u):$(id -g)" \
3  -v "$PWD/data:/app/data" \
4  ubuntu:24.04 \
5  bash -lc 'id && touch /app/data/test.txt'

If the host directory is owned by your normal user, this often fixes the problem immediately.

This is also a good default for local development containers that need to create files you will edit on the host later.

Fix by Adjusting Host Directory Ownership or Permissions

If the container must run as a fixed application user, you can instead change the host directory to match that UID and GID.

sudo chown -R 1000:1000 data
chmod -R u+rwX data

Be deliberate here. Relaxing permissions with chmod 777 may appear to work, but it is usually too broad and hides the real ownership mismatch.

Docker Compose Example

In Compose, the same approach works through the user setting.

1services:
2  app:
3    image: ubuntu:24.04
4    user: "1000:1000"
5    volumes:
6      - ./data:/app/data
7    command: bash -lc "touch /app/data/test.txt && ls -l /app/data"

For team projects, using environment variables for UID and GID can make the setup less brittle across machines.

Other Environment-Specific Causes

On plain Ubuntu with normal Docker Engine, UID and GID mismatches are the most common cause. Still, check these if the obvious fix does not work:

• rootless Docker remapping
• network filesystems mounted with restrictive options
• AppArmor or other host security policies
• directories that are writable but files inside are owned differently

These are secondary causes, but they matter once basic Unix permissions have been ruled out.

Common Pitfalls

• Assuming Docker volumes bypass host filesystem permissions.
• Debugging the application before checking the numeric UID and GID inside the container.
• Fixing the issue with overly permissive chmod 777 instead of matching ownership properly.
• Forgetting that an existing file inside the mounted directory may have different ownership from the directory itself.
• Using a development container as root and then being surprised by root-owned files on the host.

Summary

• A mounted host volume is writable only if the container process has host-level write permission.
• The usual root cause on Ubuntu is a UID and GID mismatch.
• The cleanest fix is often to run the container with the host user's UID and GID.
• Adjust host directory ownership when the container must run as a fixed application user.
• Check numeric identities first before changing broader Docker or OS settings.