I have no idea. I’m not a PHP developer, but there’s got to be some way to get the damned thing to tell us what it’s doing and give some clue about why it’s failing. If it isn’t showing up in the mail log, it never even touched the server, so there has to be some error about it!
Only works for windows not linux
php uses the command
sendmail -t -i
by default to send mail, this is set in the relevant php.ini file, if this has been altered it will not work. The default is sendmail -t -i so if either sendmail is not installed or /usr/sbin is not in the user path it will fail.
at this point perhaps running
which sendmail
as the user, will identify where sendmail is.
if this a blank result, not in the user path run
whereis sendmail
this should return the path to sendmail, most likely to be /usr/sbin/sendmail.
with this edit the relevant php.ini file to reflect the full path to sendmail, not forgetting to add -t -i to the end of the command.
or you could just ensure /usr/sbin ( or wherever sendmail is located) is added to the user path.
don’t forget to restart the relevant php instance to read the changes if you have followed the ‘edit php.ini’ route
I got this when in a Virtualmin terminal window as the user:
username@myserver:~$ clear
TERM environment variable not set.
username@myserver:~$ which sendmail
bash: which: command not found
username@myserver:~$ whereis sendmail
bash: whereis: command not found
username@myserver:~$
Through the Virtualmin file manager I edited /home/username/etc/php7.4/php.ini and found that the full path was already in there:
[mail function]
; For Win32 only.
; http://php.net/smtp
SMTP = localhost
; http://php.net/smtp-port
smtp_port = 25
; For Win32 only.
; http://php.net/sendmail-from
;sendmail_from = me@example.com
; For Unix only. You may supply arguments as well (default: "sendmail -t -i").
; http://php.net/sendmail-path
sendmail_path = /usr/sbin/sendmail -t -i
; Force the addition of the specified parameters to be passed as extra parameters
; to the sendmail binary. These parameters will always replace the value of
; the 5th parameter to mail().
;mail.force_extra_parameters =
; Add X-PHP-Originating-Script: that will include uid of the script followed by the filename
mail.add_x_header = Off
; The path to a log file that will log all mail() calls. Log entries include
; the full path of the script, line number, To address and headers.
;mail.log =
; Log mail to syslog (Event Log on Windows).
;mail.log = syslog
Please correct me if I am wrong - shouldn’t there be a path to a log file that will log all mail() calls in the “;mail.log =” line above? Is this why I’m not seeing any errors pertinent to mail from PHP?
Have you tried using another php version? Perhaps you are missing something in php7.4?
Check with other email scripts and see if the file permissions are correct with the one having issues.
southernnhgroup@myserver:~$ clear
TERM environment variable not set.
southernnhgroup@myserver:~$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
southernnhgroup@myserver:~$
Yes, all of the websites on this box are chrooted. I’ve been doing that on two Virtualmin boxes and have no issues on the first/other box.
What do you mean? Are you saying I should be checking/reviewing the files in the chroot folder itself rather than the user’s?
I ask this because when I placed scripts, etc. in the site to check it, I have been placing them in the regular username directory and not the numbered jail folder. And they ran (served) ok from there. Looking now, I see that most everything is duplicated in the chroot directories.
I use chrooting as an additional layer of security. One website hacked beats all of them hacked.
A chroot is a severely restricted environment. That’s what it’s for. A chrooted user cannot run anything you have not explicitly given them. Anything you want the user to be able to run, you need to put it into the chroot using jk_cp or by adding it to the jail config you use for users and regenerate their jail(s).
I’m not saying you should put your scripts in the numbered jail folder. I’m saying system tools need to be added to the jail using the jk utilities or the Webmin Jailkit module (though you have to regenerate the jail in that case). Every chroot is the whole operating system as far as the logged in user is concerned, and it is their own unique copy of the operating system.
You should not edit the jail folder directly, you should use the Jailkit utilities and config files to edit the jail.
chroot is not really a security feature. It is an aesthetic feature. Users in a chroot can’t see the rest of the system. But, without chroot one website hacked does not equal all websites hacked. The default permissions and ownership model in Virtualmin covers that. All domains run apps as their own user. Though these days, PHP-FPM can run inside the chroot, which closes one of the possible options for bypassing the chroot (which may be why your old sites worked within a chroot, but not now…maybe the old sites were not actually chrooted, even if the user was).
But, I recommend you get really familiar with chroots before using them. They introduce new security concerns (mitigated on some distros by use of capabilities), but also are just a lot harder to use. You need to think through everything the user needs, and make sure giving them that doesn’t introduce a security problem.
I assumed when you tested using sendmail to send mail earlier you were running it as the user that had problems. I guess that was an incorrect assumption, since it obviously can’t work for a chrooted user who doesn’t have sendmail in their jail!
I didn’t think in terms of chroot as an issue in this. However, I just checked and see that the other Virtualmin box I threw a form into a WordPress site and tested from did not have chroot active.
I haven’t noticed an east way to turn off chroot on a virtual server. Can I do that on an existing site without losing the site?
I can’t think of any reason disabling a chroot would have anything to do with the site. The site data is unrelated to the chroot; there’s a bind mount to bring it into the chroot, but it’s not actually in the chroot.
Obviously, make sure you have good backups, but I think turning off the chroot is as simple as switching to a normal shell path, instead of the magic shell path being used for chroots. (It’s been a long time since I did the research on how to implement jails, and I don’t use them myself, so it’s kinda vague in my head.)
Ok, turning off the chroot on a site seemed pretty simple, it’s at the bottom of: Administration Options > Edit Owner Limits > Other restrictions
After doing that I went and tried the form on the site I could not send email from and it worked!
I want to thank everyone here for their contributions to helping find a solution to this - and helping define the problem. I learned way more than I intended to (which is never a bad thing - ).