docker-compose.zsus.yml app container cannot read Docker volume data — executor tars a nonexistent host mountpoint, so volume backups fail in the deployed stack #54

New issue

Closed

opened 2026-08-14 11:13:37 +00:00 by Mark · 0 comments

Mark commented

2026-08-14 11:13:37 +00:00

Owner

Summary

The app service in docker-compose.zsus.yml mounts only /var/run/docker.sock, app_data:/data, and backups:/backups. The backup executor tars the Docker-reported host mountpoint /var/lib/docker/volumes/<vol>/_data, which does not exist inside the container. Volume backups fail in the deployed stack until the container is recreated with an extra bind mount.

Location

docker-compose.zsus.yml:29-32:

volumes:
  - /var/run/docker.sock:/var/run/docker.sock:ro
  - app_data:/data
  - backups:/backups

Reproduction (from kanban QA card t_3b5379e0)

docker compose -f docker-compose.zsus.yml up -d (as-is, no extra mounts).
Trigger a backup of any Docker volume via the Schedule → queue worker path.
Executor tars /var/lib/docker/volumes/<vol>/_data inside the container → path does not exist → backup fails or produces an empty/invalid artifact.
Verified workaround: recreate the app container with an extra -v /var/lib/docker/volumes:/var/lib/docker/volumes:rw → backup succeeds.

Actual vs expected

Expected: the compose file mounts the volumes directory (or the executor resolves volume data another way), so volume backups work out of the box after compose up.
Actual: the deployed stack cannot read volume data without a manual container recreate that is not recorded in the compose file (lost on any future compose up --force-recreate).

References

docker-compose.zsus.yml:29-32
Kanban card: t_3b5379e0 (QA board, fixit)

## Summary The `app` service in `docker-compose.zsus.yml` mounts only `/var/run/docker.sock`, `app_data:/data`, and `backups:/backups`. The backup executor tars the **Docker-reported host mountpoint** `/var/lib/docker/volumes/<vol>/_data`, which does not exist inside the container. Volume backups fail in the deployed stack until the container is recreated with an extra bind mount. ## Location `docker-compose.zsus.yml:29-32`: ```yaml volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - app_data:/data - backups:/backups ``` ## Reproduction (from kanban QA card t_3b5379e0) 1. `docker compose -f docker-compose.zsus.yml up -d` (as-is, no extra mounts). 2. Trigger a backup of any Docker volume via the Schedule → queue worker path. 3. Executor tars `/var/lib/docker/volumes/<vol>/_data` inside the container → path does not exist → backup fails or produces an empty/invalid artifact. 4. Verified workaround: recreate the app container with an extra `-v /var/lib/docker/volumes:/var/lib/docker/volumes:rw` → backup succeeds. ## Actual vs expected - **Expected**: the compose file mounts the volumes directory (or the executor resolves volume data another way), so volume backups work out of the box after `compose up`. - **Actual**: the deployed stack cannot read volume data without a manual container recreate that is not recorded in the compose file (lost on any future `compose up --force-recreate`). ## References - `docker-compose.zsus.yml:29-32` - Kanban card: t_3b5379e0 (QA board, fixit)