Docker secrets no longer work because the container does not run as root

[appiekap653]

Support guidelines

• I've read the support guidelines

I've found a bug and checked that ...

• ... the documentation does not mention anything about my problem
• ... there are no open or closed issues that are related to my problem
• ... it's definitely a Firefly III issue, not me

Description

After the upgrade from 6.1.25 to 6.2.* it gives the following error when starting up the docker container:

  [x]  Error when connecting to DB: SQLSTATE[HY000] [1045] Access denied for user 'firefly'@'172.33.0.14' (using password: NO)

For so far I have tried to get to the bottom of the cause, I believe it has to do with the change to the user in the container not being root anymore.

I make use of docker secrets for the passwords with the environment variables set to: /run/secrets/firefly_iii_db_password

Those secret files are owned by root and have only user r+w permissions.
This would explain why the error states that password is not used, because it cannot open the file anymore.

Debug information

see above.

Expected behaviour

No response

Steps to reproduce

No response

Additional info

No response

[foster-hangdaan]

I have upgraded to 6.2.4 from 6.1.25 and getting the same error.

Those secret files are owned by root and have only user r+w permissions. This would explain why the error states that password is not used, because it cannot open the file anymore.

The container user is no longer root in v6.2.0, so this is the most probable cause. I am also using Docker secrets to supply the database password. As more proof, I'm getting an authentication error for the mail server since I supply the SMTP password as a Docker secret as well:

[2025-02-05 16:18:55] production.ERROR: Failed to authenticate on SMTP server with username "<REDACTED>" using the following authenticators: "CRAM-M
D5", "LOGIN", "PLAIN". Authenticator "CRAM-MD5" returned "Expected response code "235" but got code "535", with message "535 Denied".". Authenticator "LOGIN" returned "Ex
pected response code "235" but got code "535", with message "535 Invalid credential".". Authenticator "PLAIN" returned "Expected response code "235" but got code "535", w
ith message "535 Invalid credential".". 

[JC5]

Hey, thanks for opening an issue!

I see tikis is some kind of Docker limitation. I'll see if I can work around it.

Cheers, James

[JC5]

https://forums.docker.com/t/only-root-user-has-access-to-the-secret/102774

Let me know if this works. Firefly III runs under the www-data user (and www-data group) which is usually 33.

[foster-hangdaan]

EDIT: Silly me, the forum linked above has the same solution. I'm still including my original response here for the record.

---

https://forums.docker.com/t/only-root-user-has-access-to-the-secret/102774

Let me know if this works. Firefly III runs under the www-data user (and www-data group) which is usually 33.

Unfortunately, these settings do not work in Podman v4.3.1. I get the following errors when setting the secret's uid, gid or mode in the compose file:

WARNING: Service "firefly-iii" uses secret "firefly-db-password" with uid, gid, or mode. These fields are not supported by this implementation of the Compose file
WARNING: Service "firefly-iii" uses secret "firefly-mail-password" with uid, gid, or mode. These fields are not supported by this implementation of the Compose file

Solution

What did work for me was to change the permission of the secret's source file. For example, if you have secrets declared like so:

secrets:
  firefly-db-pass:
    file: ./db-pass.txt

The permissions of db-pass.txt are currently set to 600 (rw only for the user). To apply the fix, set the file to be globally readable:

chmod 644 ./db-pass.txt

The secret should now be mounted with the new permissions within the container the next time they are launched with podman-compose up.

[JC5]

I've expanded the text in the documentation to account for these things.