Ah, this is a super common issue with Docker volumes! The problem here is that when Docker creates a named volume (like your source_data), it defaults to being owned by the root user inside the container. If your service-test image runs its application as a non-root user (which is a security best practice), that user won't have write access to /temp/config.

Here are a few solid solutions to get this working:

1. Fix Permissions in the Dockerfile (Recommended) #

If you have control over building the service-test image, this is the cleanest long-term fix. Just update your Dockerfile to ensure the /temp/config directory is owned by the user your app runs as:

# First, create the non-root user if you haven't already
RUN useradd -m appuser

# Create the config directory and set proper ownership
RUN mkdir -p /temp/config && chown -R appuser:appuser /temp/config

# Switch to the non-root user to run the app
USER appuser

Rebuild your image, then restart your Docker Compose stack. The volume will now inherit the directory's permissions from the container, so your app can write to it without issues.

2. Adjust Permissions Without Modifying the Image #

If you can't rebuild the image, try these workarounds:

Option 2.1: Run the Container as Root (Not Ideal, But Quick) #

You can force the container to run as root, which will have full access to the volume. Add the user: root line to your service definition:

version: '2'
services:
  service-test:
    image: service-test:latest
    container_name: service-test
    user: root  # Add this line
    volumes:
      - source_data:/temp/config/
volumes:
  source_data:

⚠️ Heads up: Running containers as root is a security risk, so only use this for testing or temporary fixes.

Option 2.2: Pre-set Permissions on the Named Volume #

You can spin up a temporary container to modify the permissions of the source_data volume before starting your service:

1. First, run this command to set the volume's ownership to the UID/GID your app uses (replace 1000:1000 with the actual UID/GID from your container—you can get this by running docker exec -it service-test id if the container can start at all):

docker run --rm -v source_data:/temp/config busybox chown -R 1000:1000 /temp/config

2. Then start your stack normally:

docker-compose up -d

3. Use a Bind Mount Instead of a Named Volume #

If you don't need Docker's managed named volume features, you can use a host directory as a bind mount. Just create the directory on your host first and set the right permissions:

1. Create the host directory and fix permissions:

mkdir -p /host/path/to/config
chown -R 1000:1000 /host/path/to/config

2. Update your docker-compose.yml to use this directory:

version: '2'
services:
  service-test:
    image: service-test:latest
    container_name: service-test
    volumes:
      - /host/path/to/config:/temp/config/

One quick tip: If you're not sure what UID/GID your app uses, try running docker run --rm service-test:latest id—this will output the user info from the container even if it can't start fully due to permission issues.

内容的提问来源于stack exchange，提问作者Mark Estrada