How to Fix Docker Permission Denied on Google Cloud Run

As a Senior DevOps Engineer on WebToolsWiz.com, let’s cut straight to resolving “Docker Permission Denied” errors on Google Cloud Run. This issue usually stems from container-internal filesystem access problems, not the Docker daemon itself on Cloud Run’s managed environment.

Fixing “Docker Permission Denied” on Google Cloud Run

1. The Root Cause

On Google Cloud Run, “Docker Permission Denied” most often signifies an issue within your container where the application attempts file system operations (like writing to a directory or creating files) without sufficient privileges. This typically happens when your Dockerfile explicitly sets a non-root USER and fails to grant that user appropriate ownership or write permissions to necessary application directories.

2. Quick Fix (CLI)

This quick fix involves temporarily running your container as root to bypass internal file system permission checks. Note: Running as root is generally not recommended for production due to security implications.

  1. Modify your Dockerfile: Temporarily remove or comment out any USER instruction (e.g., USER node, USER appuser). By default, containers run as root if no USER is specified. 
    # Before (problematic):
# USER appuser

# After (temporary fix):
# # USER appuser - Temporarily commented out for root execution
  2. Rebuild and Push the Image: 
    gcloud builds submit --tag gcr.io/YOUR_PROJECT_ID/your-app:latest . --project YOUR_PROJECT_ID
  3. Deploy the Updated Image to Cloud Run: 
    gcloud run deploy YOUR_SERVICE_NAME \
  --image gcr.io/YOUR_PROJECT_ID/your-app:latest \
  --platform managed \
  --region YOUR_REGION \
  --project YOUR_PROJECT_ID \
  --allow-unauthenticated # Adjust authentication as needed

This redeployment will force your container to run as root, often immediately resolving internal “Permission Denied” errors and confirming that the issue was indeed related to user permissions within the container.

3. Configuration Check

The secure and recommended solution involves adjusting your Dockerfile to explicitly grant the chosen non-root user the necessary permissions.

Edit your Dockerfile to include user and permission management before switching to the non-root user:

# Example for a Node.js application needing to write to /app/data
FROM node:18-slim
WORKDIR /app

COPY package*.json ./
RUN npm install --omit=dev

COPY . .

# Create a dedicated non-root user
RUN groupadd -r appuser && useradd -r -g appuser appuser

# Create directories that need writing access and set ownership/permissions
# Example: If your app writes to /app/data
RUN mkdir -p /app/data && chown appuser:appuser /app/data && chmod 755 /app/data

# Ensure main application directory has appropriate permissions (optional, but good practice)
# If your app needs to write directly to /app, adjust accordingly.
RUN chown -R appuser:appuser /app

# Switch to the non-root user
USER appuser

EXPOSE 8080
CMD ["npm", "start"]

Key Changes:

  • RUN groupadd -r appuser && useradd -r -g appuser appuser: Creates a dedicated non-root user.
  • RUN mkdir -p /app/data && chown appuser:appuser /app/data && chmod 755 /app/data: Creates the specific directory your application needs to write to, assigns ownership to appuser, and sets read/write/execute permissions.
  • USER appuser: Switches the container process to run as appuser. Ensure this is the last USER instruction before CMD or ENTRYPOINT.

Adjust /app/data to the actual path(s) your application attempts to write to.

4. Verification

After implementing the secure Dockerfile changes, rebuild and redeploy your service to verify the fix.

  1. Rebuild Image with Secure Dockerfile: 
    gcloud builds submit --tag gcr.io/YOUR_PROJECT_ID/your-app:v1.0.1 . --project YOUR_PROJECT_ID
  2. Redeploy Service to Cloud Run: 
    gcloud run deploy YOUR_SERVICE_NAME \
  --image gcr.io/YOUR_PROJECT_ID/your-app:v1.0.1 \
  --platform managed \
  --region YOUR_REGION \
  --project YOUR_PROJECT_ID
  3. Monitor Logs: Access the Cloud Run service logs in the Google Cloud Console (or via gcloud run services logs YOUR_SERVICE_NAME --region YOUR_REGION --project YOUR_PROJECT_ID) to confirm that “Permission Denied” errors no longer appear and your application functions as expected.

⚡ Related Troubleshooting Guides