Notification emails from cron.php sent as no-reply@localhost instead of no-reply@my-domain

Set up Nextcloud 24.0.4 as Plesk Obsidian Extension (under Ubuntu 18.04.6 LTS) on a hosted subdomain. Then, also in Plesk made sure that cron.php is executed periodically, using “Scheduled Tasks” for that same subdomain. This guarantees that all permissions and the user that this executes under are correct. Email notifications are working fine, but are sent as FROM:no-reply@localhost which triggers spam filters in the clients. When I test the email function in the web interface, emails are sent correctly as FROM:no-reply@my-domain.

How can I fix this?

The email settings for system notifications, such as from a crontab, are independent of the settings you made in an application such as Nextcloud. I don’t use Plesk myself, but I would assume that you can configure the necessary settings directly in Plesk.

In this case crontab or the system doesn’t send the email but crontab calls cron.php via php and cron.php uses Nextcloud. So it’s either a php or Nextcloud issue, the Plesk settings are fine as far as I can tell. System-wide outgoing mail mode is set to “Send from domain IP addresses and use domain names in SMTP greeting”.
To prove my point, if it were a system-generated email, it wouldn’t be sent from no-reply@… because no-reply is not a user, it would use username@…

Ah ok. Not sure why it doesn’t use the email settings in Nextloud then. I never used cron.php and I would not recommand doing so, unless you absolutly have to. Doesn’t your hosting provider offer an option to set up cronjobs?

Using cron is the recommended method, the default didn’t send out notifications for changed files at all in my case. See

And yes, I used the hosting provider’s recommended method for periodic execution of cron jobs
from within the same donain’s hosting settings, using the same PHP version that I use for Nextcloud.

Yeah right sorry for the confussion. My bad.

There are two ways to set up a cronjob in Nextcloud. (actually three but let’s not talk abpout AJAX)

“webcron”, which is not recommanded or “Cron”, which is the recommanded way. Also this is appearently what you are using. So far so good.

Ok. But then my first statement was correct after all. If you choose the “Cron” option in Nextcloud, the cron.php will be executed by cron on the underlying system, which does not use the email settings you have configured in Nextcloud. The email settings releated to the cron job itself, which is handeld by Plesk, respective the underlying system, must also be set up in Plesk, not in Nextcloud.

Nope, sorry. As I added to my first reply, cron.php (or rather what is called underneath) sets up the sender email address as no-reply@something and cron.php is not an independent entity but calls upon the Nextcloud base for everything it does.
A system-generated email would always use username@… for sending emails, never no-reply@…

You have to destict between messages sent by Nextcloud itself like e.g calendar notifications and messages sent by the cron deamon itself. The former uses the settings in nextcloud, the latter uses the settings of Plesk respective the underlying system.

I do know the difference and I already proved that these notifications can’t possibly be sent from the cron deamon itself.

Aight, noted. Sorry if I didn’t get it at first glance. Probably should have read your post more carefully before answering :wink: With that out of the way, my next question would be:

Are you using the “Sendmail” or the “SMTP” option in Nextcloud?

If you are using sendmail, it uses the Sendmail executable on the underlying system or any drop-in Sendmail replacement such as Postfix, Exim etc… And this is very likely also controlled by Plesk and maybe the “From Address” gets somehow overwritten before it sends the mail…?

However I would recommend to use the SMTP option with authentication. Usually with web hosting packages you also get a bunch of free email addresses and with them you can use the SMTP server of the hosting company in order to send emails from the appliactions you are hosting.

Found the issue. There is a setting in config/config.php:

‘overwrite.cli.url’ => ‘[url to server]’,

which was set to “http://localhost” by default. After setting it to the correct URL

  • the FROM: email domain would be correct
  • the links embedded in the notification emails would be correct

So this was “it”.