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!