bonaminandClaude Opus 5.5
18705aaefb
751cac7 switched the base compose file to an external named volume
(bellsystems-postgres-data) to dodge a WSL2/Docker Desktop bind-mount bug.
That volume only exists on the Windows dev machine: on the VPS, where the
push auto-deploys via deploy-host.sh, `docker compose up` would fail on the
missing external volume (or, if created, start Postgres on an empty
database while the real data sat unused in ./data/postgres).
The base file goes back to the ./data/postgres bind mount the server has
always used (Linux has no such bug). The named volume now lives in
docker-compose.override.yml, which Compose loads automatically, is
gitignored, and is created from docker-compose.override.example.yml on
Windows machines only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
19 lines
793 B
YAML
19 lines
793 B
YAML
# Windows / Docker Desktop dev machines only — copy to docker-compose.override.yml
|
|
# (gitignored; Docker Compose loads it automatically). The server does NOT use this.
|
|
#
|
|
# Why: a ./data/postgres bind mount onto the Windows filesystem hits a
|
|
# WSL2/Docker Desktop bug where the 9p/virtiofs bridge reports normal
|
|
# postgres:postgres 0600 ownership but the kernel still refuses the postgres
|
|
# user's own open() calls for write — silent on read, fatal on any WAL write.
|
|
# A Docker-managed named volume lives inside the WSL2 VM's own filesystem and
|
|
# avoids it. Create it once with: docker volume create bellsystems-postgres-data
|
|
services:
|
|
postgres:
|
|
volumes:
|
|
- postgres-data:/var/lib/postgresql/data
|
|
|
|
volumes:
|
|
postgres-data:
|
|
name: bellsystems-postgres-data
|
|
external: true
|