Hello 

I also got the same issue but sorted out actually while we transfer the data then the permission is changed so you need to set permissions for that as 102 104 by following command 

chown 102:104 <folder/file> like this you need to do for every object ... better  leave it 

Thanks

So, I came up with a following solution for my case — testing migration from one machine to another.

I switched to a Docker Compose based setup on a target machine with data and db volumes managed by Docker. In such case, indeed, one should follow Docker documentation on moving data volumes. Although, the original docs are somewhat difficult to understand. Here is a quick overview of the steps.

• On the source machine
  • create a Docker container backup with opdata and pgdata volumes mounted to it
  • run a disposable container that takes volumes from backup and creates zip/tar archives on the source machine
• On the target machine
  • again, create a containter restore with target opdata and pgdata volumes mounted to it
  • run a disposable container that takes backup archives and unzips/untars them into the target volumes
  • that's it! On the next spin-off of your docker-compose OP will pick up the transferred db and user data

There is one more thing if you want to test the transfer to a local machine: if the source OP instance was configured to use https, then you wouldn't get pass the login screen and would get an error message. To solve this without altering the OP configuration, just spin-off a reverse proxy with self-signed certificates and route the localhost traffic to the replica OP instance through it.

Some useful resources for the scenario:

• Docker volumes backup and restore (official docs) or just google for tutorials (worked for me)
• Self-signed SSL Reverse proxy with Docker (worked for me on macOS with some extra tweaks in networking between proxy and OP containers)