Comment

Comment on Trouble moving a container and its data to another server

Thanks a lot! I certainly need to learn about permissions and docker mapped directories in general. This is still very unclear in my head and it prevents me from troubleshooting my own stuff which is frustrating. You’re all very cool but I’d like to not post a lemmy every time an app has wrong permissions haha. I’ll have a read.

source

Sort:hotnew top

CumBroth@discuss.tchncs.de ⁨1⁩ ⁨year⁩ ago
In response to your update: Try specifying the user that’s supposed to own the mapped directories in the docker compose file. Then make sure the UID and GID you use match an existing user on the new system you are testing the backup on.

First you need to get the id of the user you want to run the container as. For a user called foo, run id foo. Note down the UID and GID.

Then in your compose file, modify the db_recipes service definition and set the UID and GID of the user that should own the mapped volumes:

db_recipes: restart: always image: postgres:15-alpine user: "1000:1000" # Replace this with the correct UID and GID matching your user volumes: - ./postgresql:/var/lib/postgresql/data env_file: - ./.env

Recreate the container using docker compose up -d (don’t just restart it; you need to load the new config from the docker compose file). Then inspect the postgresql directory using ls -l to check whether it’s actually owned by user with UID 1000 and group with GID 1000. This should solve the issue you are having with that backup program you’re using. It’s probably unable to copy that particular directory because it’s owned by root:root and you’re not running it as root (don’t do that; it would circumvent the real problem rather than help you address it).

Now, when it comes to copying this to another machine, as already mentioned you could use something that preserves permissions like rsync, but for learning purposes I’d intentionally do it manually as you did before to potentially mess things up. On the new machine, repeat this process. First find the UID and GID of the current non-root user (or whatever user you want to run your containers as). Then make sure that UID and GID are set in the compose files. Then inspect the directories to make sure they have the correct ownership. If the compose file isn’t honoring the user flag or if the ownership doesn’t match the UID and GID you set for whatever reason, you can also use chown -R ./postgresql to change ownership.
source