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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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 deniedServices 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 firstabra app deploy, Docker registers the unknown volume and chowns the_datadir toroot: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 withdocker 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 (-dwithout-s) probably has the same issue.When I need this again, I can write the fix and test.
If of any use:
abra app movearrived in the meantime.Yes, saw that. But
abra app renamehasn't arrived yet.