Docker container permission issues in CI/CD environment but works fine on local machine

[SurfingWave]

I’m having trouble with a Docker Compose setup that runs perfectly on my local development environment but consistently fails when executed in our CI/CD pipeline. The container crashes with a permission error when trying to access its configuration directory.

The error message I keep getting is:

Error: EACCES: permission denied, open '/home/node/.n8n/config'

Here’s my Docker Compose configuration:

workflow-engine:
  image: docker.n8n.io/n8nio/n8n
  ports:
    - "8080:5678"
  environment:
    - N8N_HOST=workflow-engine:5678
    - N8N_PORT=5678
    - N8N_PROTOCOL=http
    - NODE_ENV=production
    - DB_TYPE=postgresdb
    - DB_TABLE_PREFIX=workflow_
    - DB_POSTGRESDB_DATABASE=workflows
  volumes:
    - ./docker/workflow/config:/home/node/.n8n
    - ./docker/workflow/storage:/storage

In my CI pipeline, I’ve tried various approaches to fix the permissions:

sudo useradd -m nodeuser
mkdir -p docker/workflow
sudo chmod -R 755 docker/workflow
sudo chown -R nodeuser:nodeuser docker/workflow
docker-compose up -d

I’ve even tried setting 777 permissions as a last resort, but nothing seems to work. The container starts fine locally on both macOS and Linux environments, but fails consistently in the automated pipeline. Has anyone encountered similar permission issues with containerized applications in CI environments?

[FlyingLeaf]

This is a common issue with CI environments handling Docker differently than your local setup. I fixed it by building a custom image that sets up the user and permissions during the build process instead of trying to fix it at runtime. Just create a Dockerfile that extends the n8n image and adds the proper user config. You could also use an init container or entrypoint script to create the directories with correct ownership before the main app starts. Here’s the thing - CI runners have different security contexts and user mappings than your local Docker daemon. Don’t fight the permissions on the host side, let Docker handle the user mapping internally. Also check if your CI platform has specific Docker user namespace settings that might be messing with the standard UID mapping.

[alexlee]

This is a UID/GID mismatch between your CI environment and the container’s user permissions. The n8n container runs as user node with a specific UID, but your CI system’s using a different user context. Don’t mess with host permissions. Add user config to your compose file instead. You can override the container’s user with user: "1000:1000" in your workflow-engine service, or better yet, use user: "${UID:-1000}:${GID:-1000}" and export these variables in your CI script. What worked for me was creating the mounted directories with proper ownership before starting containers. In your CI pipeline, run mkdir -p docker/workflow/config docker/workflow/storage && chown -R 1000:1000 docker/workflow before the docker-compose command. This ensures the directories exist with the right ownership that matches the container’s internal user.

[TomDream42]

i had similar issue, ended up using a named volume instead of bind mount. it helped with permissions a lot. also check if your CI runner is running as root or not, that can cause issues too. hope this helps!