Top Menu

Jump to content
Home
    Modules
      • Projects
      • Activity
      • Work packages
      • Gantt charts
      • Calendars
      • Team planners
      • Boards
      • News
    • Getting started
    • Introduction video
      Welcome to OpenProject Community
      Get a quick overview of project management and team collaboration with OpenProject. You can restart this video from the help menu.

    • Help and support
    • Upgrade to Enterprise edition
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Enterprise support

    • Additional resources
    • Data privacy and security policy
    • Digital accessibility (DE)
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation
  • Sign in
      Forgot your password?

      or sign in with your existing account

      Google

Side Menu

  • Overview
  • Activity
    Activity
  • Roadmap
  • Work packages
    Work packages
  • Gantt charts
    Gantt charts
  • Calendars
    Calendars
  • Team planners
    Team planners
  • Boards
    Boards
  • News
  • Forums

Content

Support Installation & Updates
  1. OpenProject
  2. Forums
  3. Support Installation & Updates
  4. Docker, external volumes and Postgres data permissions

Docker, external volumes and Postgres data permissions

Added by Aleksandrs A almost 5 years ago

What happened: 

  • On a local machine (mac) I launched an OP Docker container with mounted folders, as described in the documentation, all fine. 
  • Then I tried to migrate the data to a remote server and to launch a new container there. So far, with no success. 
    • On any attempt to move the data folders across machines, the same type of Postgres error pops within the container:
Starting PostgreSQL 9.6 database server: 
mainError: Config owner (postgres:102) and data owner (app:1000) do not match, 
and config owner is not root ... failed! failed!

The same error goes on if I try to move the data created by a container on a remote machine to my local machine.

There are variations of owner and data owner depending on the direction of migration (machine1 to machine2, or machine2 to machine1).

Moreover, the same error suddenly started to pop also on attempts to re-launch a container created via Kitematic.

I tried many possible scenarios, including altering permissions on data folders, but nothing worked so far. Some solutions on the net refer to manipulating with permissions within the container, but this doesn't help if it can't be launched in the first place.

It would be just great to establish what can be done to mitigate such errors. Thanks in advance for any help on this!


Replies (2)

RE: Docker, external volumes and Postgres data permissions - Added by Surendra Gupta almost 5 years ago

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

RE: Docker, external volumes and Postgres data permissions - Added by Aleksandrs A almost 5 years ago

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)
  • (1 - 2/2)
Loading...