fix: resolve Docker Compose permission denied errors for mounted volumes #629
+13
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix: Resolve Docker Compose Permission Denied Errors
Overview
This Pull Request addresses issue #591 by fixing the "permission denied" errors that occur when running Docker Compose with mounted volumes.
Problem
When users attempt to run the indexer using Docker Compose:
They encounter permission denied errors because:
postgresandnatscontainers run as internal users (postgres user, nats user)./target/data/postgres,./target/data/nats), the container cannot write to them due to ownership mismatchThis is a common Docker issue that affects many users, especially on Linux systems where file permissions are strictly enforced.
Solution
Added explicit user mapping to the affected services in
docker-compose.yaml:This configuration:
UIDandGIDenvironment variables if set1000:1000(common default for first user on Linux)Changes
docker-compose.yaml
Added
userdirective to:postgresservice (line 129)natsservice (line 152)Added explanatory comments for clarity.
README.md
Added documentation in the "Using Docker Compose" section explaining:
Usage
After this fix, users can run Docker Compose in two ways:
Option 1: Use defaults (works for most users)
Option 2: Explicitly set UID/GID (recommended)
Testing
This fix has been validated by:
Impact
This is a non-breaking change that:
Related Issues