docker
docker copied to clipboard
Config 'mail_smtpauth' not set when using docker secrets handling in docker-compose
Hi,
I am changing my docker-compose to use the secrets file handling and realized the config 'mail_smtpauth' is no longer set to 1 in the config.php. Looking into the smtp.config.php line 8 I see the 'mail_smtpauth' is only set when using "SMTP_NAME" and "SMTP_PASSWORD" but not when using "SMTP_PASSWORD_FILE".
Maybe the line could be changed to something like: 'mail_smtpauth' => getenv('SMTP_NAME') && (getenv('SMTP_PASSWORD') || getenv('SMTP_PASSWORD_FILE')),
I'm also experiencing an issue with using "SMTP_PASSWORD_FILE". I wonder if they are related.
For some reason I have to set the owner of the secrets file for the SMPT password to 82:root in order for it to work. Otherwise I get the following error on startup:
file_get_contents: Failed to open stream: Permission denied in /var/www/html/config/smtp.config.php
I am using secrets for all the other passwords in the NextCloud docker-compose config as well, however, they are read without setting any special owner/permission on the secrets file.
I have the same problem and am using SMTP_PASSWORD_FILE
. I was able to get around it by setting an environment variable: NC_mail_smtpauth=true
. I did this in the environment
section of my docker-compose.yml
:
environment:
- NC_mail_smtpauth=true
I had to do the same thing in my cron container since I started getting Swift_TransportException
exceptions in my log (the one within the web app), with the message Expected response code 250 but got code "530", with message "530 5.7.1 Authentication required "
. If you look at the stack trace, it's coming from /var/www/html/cron.php
.
+1 for setting mail_smtpauth
automatically if using SMTP_PASSWORD_FILE
You are referring to https://github.com/nextcloud/docker/blob/31c59aea24f8516f862ca136766168016e840593/.config/smtp.config.php#L8
It appears that after this issue was created a fix was implemented by d447c57
Please consider closing this issue.
Hi @ramIsCoding - Thanks for the report. This was fixed in #1614 in September 2022. Unless you can reproduce this behavior today, please close this Issue out to avoid confusion. Thanks!