Permissions Issues with Creating Backup???

[kevdogg]

I'm actually not sure what the error is attributable to. Here is my error:

time="2024-12-03T17:38:00Z" level=debug msg="starting dump"
time="2024-12-03T17:38:00Z" level=info msg="beginning dump 2024-12-03T17:38:00Z" run=627211e8-32ba-4956-bcd3-a84685306ca0
time="2024-12-03T17:38:01Z" level=debug msg="uploading via protocol file from db_backup_2024-12-03T17:38:00Z.tgz to db_backup_2024-12-03T17:38:00Z.tgz" run=627211e8-32ba-4956-bcd3-a84685306ca0
Error: error running command: error running command: error running dump: failed to push file: open /tmp/databacker_backup1650887563/db_backup_2024-12-03T17:38:00Z.tgz: no such file or directory

Here is my compose file sections:

  mariadb:
    container_name: mariadb
    image: ghcr.io/linuxserver/mariadb:latest
    restart: always
    hostname: mariadb-bitwarden_rs
    secrets:
      - mysql-user_secret
      - mysql-root_secret
    networks:
      - bitwarden_rs_net
    ports:
      - 3306:3306
    healthcheck:
      <<: *mariadb-healthcheck
    environment:
      - TZ
      - PUID=0
      - GUID=0
      - MYSQL_DATABASE=bitwarden
      - FILE__MYSQL_ROOT_PASSWORD=/run/secrets/mysql-root_secret
      - MYSQL_USER=bwuser
      - FILE__MYSQL_PASSWORD=/run/secrets/mysql-user_secret
      #- MYSQL_PASSWORD=bwuserpass
    volumes:
      - /var/data/db:/config
      - /etc/localtime:/etc/localtime:ro

  mariadb-backup:
    container_name: mariadb-backup
    image: databack/mysql-backup:latest
    restart: unless-stopped
    #user: root
    secrets:
      - mysql-root_secret
      - mysql-user_secret
    networks:
      - bitwarden_rs_net
    depends_on:
      <<: *mariadb-depends
    command: dump
    environment:
      - TZ
      - DB_SERVER=mariadb
      - DB_PORT=3306
      - DB_USER=bwuser
      - DB_PASS=bwuserpass
      - DB_DUMP_FREQUENCY=180
      - DB_DUMP_RETENTION=4w
      - DB_DEBUG=true
      - DB_RUN_ONCE=true
      - DB_DUMP_TARGET=/backup
      - DB_NAMES=bitwarden
    volumes:
      - /var/data/bw-mysql-data-backup:/backup
      - /var/data/scripts/source.sh:/scripts.d/source.sh
      - /var/data/scripts/source.sh:/scripts.d/target.sh
      - /var/data/scripts/pre-backup:/scripts.d/pre-backup
      - /var/data/scripts/post-backup:/scripts.d/post-backup
      - /etc/localtime:/etc/localtime:ro

I'm not sure if I'm looking at a file permissions issue here of what?

[deitch]

open /tmp/databacker_backup1650887563/db_backup_2024-12-03T17:38:00Z.tgz: no such file or directory

This implies that it is not where it is pushing it to that is the problem - which would be a permissions error - but reading the temporary dump file. When it dumps, it creates a single temporary dump file with all of the info, and then it uses the protocol (in your case, file) to send it to the target.

Why it should not be able to read it is confusing. I don't think traces will help, but you can add --trace-stderr (or env var TRACE_STDERR=true to dump the traces. But I think that just will confirm what we believe to be true: it successfully did a dump, creates the local file, and then failed to find the local file when time to push.

It is possible that it is a permissions issue, but that would surprise me. Still, try uncommenting the user: root and see if anything changes? And, to be sure, maybe run it once without /backup mounted in, just to eliminate it?

[kevdogg]

Hmm I'll post my modified Docker compose file, but after eliminating all bind mounts, adding the env variable TRACE_STDERROR, and eliminating user 0:0, I'm really getting the same error. I'm kinda stuck when trying to debug the problem because the container is continually restarting.

Ok - after looking at your dockerfile I think I see the problem. You created a non-root user and group of 1005:1005. The /backup directory was bind mounted but was owned by root:root with 755 permissions. Clearly the 1005 user/group was failing to be able to write because of the wrong permissions. Once I bind mounted a /backup directory owned on the docker host by 1005:1005, then things worked again.

Not trying to complain, but can you advertise somewhere there is a non-root container. I'm aware that's the usual recommendations presently for security purposes, however I'm no docker experts, but usually everyday common users on a system -- their numbering on arch at least starts at 1000. I've oftened wondered when people create non-root containers why they create UIDs and GIDs that start anywhere near 1000 to avoid possible conflict with regular users on the system. Usually if I have a Dockerfile trying to recreate as non-root, I'll start with UID/GID of 10,000 or some very large number.

Thanks for help

[deitch]

Clearly the 1005 user/group was failing to be able to write because of the wrong permissions. Once I bind mounted a /backup directory owned on the docker host by 1005:1005, then things worked again.

Nice catch. And that also means that the log message is misleading, because it looked like it could not read the staging file, not that it could not write the target file. Worth adding a little more verbosity to that.

Not trying to complain

Why not? 😄

can you advertise somewhere there is a non-root container

Does this help?

[kevdogg]

Yea thanks for updating the documentation.

…

On Wed, Dec 4, 2024 at 12:39 PM Avi Deitcher ***@***.***> wrote: Clearly the 1005 user/group was failing to be able to write because of the wrong permissions. Once I bind mounted a /backup directory owned on the docker host by 1005:1005, then things worked again. Nice catch. And that also means that the log message is misleading, because it looked like it could not *read* the staging file, not that it could not *write* the target file. Worth adding a little more verbosity to that. Not trying to complain Why not? 😄 can you advertise somewhere there is a non-root container Does this <https://github.com/databacker/mysql-backup/blob/f540139008670baa761437d77002b441455ad886/docs/container_considerations.md> help? — Reply to this email directly, view it on GitHub <#386 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABH75V7OWIRSDREGSUUFGW32D5D7NAVCNFSM6AAAAABS6KUM4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJYGI2TANBYGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[deitch]

See #387 for the misleading errors.