"Unable to initialize messaging context!"

[cynik606]

Hi,
I'm using image in QNAP conatainer.
In terminal I see only this:
"Starting at Fri Mar 14 19:05:39 UTC 2025
./
./backup_2025-03-14T19:06:39Z.sql
Unable to initialize messaging context!"
Any idea?

[deitch]

Ok that's pretty cool. I've got a synology and run all sorts of local maintenance things on containers in there.

Run it with debug enabled and post the output here. The configuration for debug is in CONFIGURATION.md. Also post your config.

It should filter out confidential information, but you shouldn't rely on it. Read through the output yourself before posting here.

[cynik606]

I've added "DB_DEBUG"=true in variables but I don't see any change in terminal output.
Maybe it's not important but I have to say that I'm trying to use 3 years old docker image exported from my previous device and imported to the new one. On the old one it was running without any problem for years.
I'd like to test the latest version of "mysql-backup" but it's not starting. In the "Command" field with the old image I was using "docker run -d --restart=always":

Terminal output using the latest image:
Error: unknown command "docker" for "mysql-backup" Run 'mysql-backup --help' for usage. FATA[0000] unknown command "docker" for "mysql-backup"

[deitch]

Ah, yes, that would be it. 3 years ago, it probably was the old (script-based) one. It now is compiled and a lot more capable.

In the "Command" field with the old image I was using "docker run -d --restart=always":

The command should not be docker run (that is implicit in running the container) but the command to run inside the container.

The backup docs in the README say this:

docker run -d --restart=always -e DB_DUMP_FREQUENCY=60 -e DB_DUMP_BEGIN=2330 -e DB_DUMP_TARGET=/local/file/path -e DB_SERVER=my-db-address -v /local/file/path:/db databack/mysql-backup dump

That is if you are running on the command line. You already have docker run implicit in the fact that you are running it using docker. -d probably is unnecessary but is controlled by your user interface. The -e options are environment variables as key-value pairs. I don't have a QNAP, but it is likely in the Environments tab.

The command you need is just dump.

[cynik606]

Thanks for quick response. Now it's better but something's wrong with permissions:
INFO[0060] beginning dump 2025-03-16T15:21:29Z run=9a06ec51-2a14-4986-a2a4-f34897050bc2 Error: error running command: error running command: error running dump: failed to push file: permission denied FATA[0076] error running command: error running command: error running dump: failed to push file: permission denied

I'm using SMB for dump - the list of my variables:
DB_SERVER = IP
DB_USER = root
DB_PASS = root's pass
DB_DUMP_BEGIN = +1
DB_DUMP_FREQ = 1440
DB_DUMP_TARGET = smb://192.168.1.5/Container/backup/mysql
SMB_USER = cntr
SMB_PASS = cntr's pass
DB_PORT = 3306

I logged on with the account "cntr" and I can create/delete data on this share (192.168.1.5/Container/backup/mysql) without any problem so I don't think that is really permissions issue.

[deitch]

Are you running with debug enabled? Try that, see if it gives any more hints. I suspect it won't, that it is a permissions question, but it might explain exactly what it is trying to do when it fails.

[cynik606]

With debug:
DEBU[0000] starting dump INFO[0060] beginning dump 2025-03-16T19:34:58Z run=5ce46b3d-a4f5-47e9-a5f8-11230881e2be DEBU[0076] uploading via protocol smb from db_backup_2025-03-16T19:34:58Z.tgz to db_backup_2025-03-16T19-34-58Z.tgz run=5ce46b3d-a4f5-47e9-a5f8-11230881e2be Error: error running command: error running command: error running dump: failed to push file: permission denied FATA[0076] error running command: error running command: error running dump: failed to push file: permission denied

Strange thing is that with fake user/password I get the same error message...

[cynik606]

Tried with different shares and smb user - always the same error about permissions :-(

[deitch]

I have been trying to reproduce this, without success. I want to recreate your setup, maybe it is losing the credentials somewhere? Or perhaps the path?

Do you have access logs on the SMB server? Can you see what username it used, what path it tried to access, and why it failed? That would help. I will try on the other side in the meantime.

[cynik606]

I couldn't find the reason of this smb failure so I decided to workaround this problem creating storage mapping for this container:

[deitch]

Ah both the backup process and the SMB target are on the same QNAP? I didn't realize.

It still bothers me, I want to know why this isn't working. If you have a chance to grab share-side logs and post them, I would appreciate it.

[deitch]

@cynik606 do you mind trying something? See if DB_SMB_USER and DB_SMB_PASS work? I know, the docs say it should be SMB_USER and SMB_PASS, so if this works, we will need either to fix the env var or change the docs. It would help to see if that does it. Thanks in advance.

[cynik606]

Ah both the backup process and the SMB target are on the same QNAP? I didn't realize.

Yes, it is so. SMB share is located on the same QNAP as the container.

See if DB_SMB_USER and DB_SMB_PASS work?

The same output in the terminal for new variables:

:-(

[deitch]

Thanks, it was the easy thing to try.

[deitch]

OK, I got it, and I know why the tests passed and this failed. I appreciate your pushing on this so I could find it. I am going to reopen this issue, so the PR can mark against this as closed. Thank you again.