Volume ownership reset on first deploy after migration #2

New Issue

2026-07-10T17:50:09Z

dannygroenewegen commented

2026-07-10 17:50:09 +00:00

After migrating an app to a new server with migrabrator, services that write files directly in their volume root fail on the first deploy. Ran into this with Prometheus from monitoring-ng:

Fatal error: opening storage failed: lock DB directory: open /prometheus/lock: permission denied

Services that only write inside subdirectories (e.g. Loki) start fine, so this issue can go partially unnoticed.

Migrabrator rsyncs volume data to /var/lib/docker/volumes/<new_name>/ before the volume exists in Docker's volume database. The rsync itself preserves ownership correctly. But on the first abra app deploy, Docker registers the unknown volume and chowns the _data dir to root:root 0755, even though it already exists and has data. Contents keep their ownership; only the volume root is reset. Any container user can't create files directly in the volume root.

Fix
In copy_volumes(), register the volume on the target with docker volume create <volume_name> before rsyncing into it. Once the volume is known to Docker, the rsynced ownership survives deploys. The same-server rename path (-d without -s) probably has the same issue.

When I need this again, I can write the fix and test.

After migrating an app to a new server with migrabrator, services that write files directly in their volume root fail on the first deploy. Ran into this with Prometheus from monitoring-ng: `Fatal error: opening storage failed: lock DB directory: open /prometheus/lock: permission denied` Services that only write inside subdirectories (e.g. Loki) start fine, so this issue can go partially unnoticed. Migrabrator rsyncs volume data to `/var/lib/docker/volumes/<new_name>/` before the volume exists in Docker's volume database. The rsync itself preserves ownership correctly. But on the first `abra app deploy`, Docker registers the unknown volume and chowns the `_data` dir to `root:root 0755`, even though it already exists and has data. Contents keep their ownership; only the volume root is reset. Any container user can't create files directly in the volume root. **Fix** In `copy_volumes()`, register the volume on the target with `docker volume create <volume_name>` before rsyncing into it. Once the volume is known to Docker, the rsynced ownership survives deploys. The same-server rename path (`-d` without `-s`) probably has the same issue. When I need this again, I can write the fix and test.

decentral1se commented

2026-07-10 18:36:38 +00:00

If of any use: abra app move arrived in the meantime.

If of any use: `abra app move` arrived in the meantime.

dannygroenewegen commented

2026-07-10 19:04:31 +00:00

If of any use: abra app move arrived in the meantime.

Yes, saw that. But abra app rename hasn't arrived yet.

> If of any use: `abra app move` arrived in the meantime. Yes, saw that. But `abra app rename` hasn't arrived yet.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: moritz/migrabrator#2