PHP mail()失败主因是PHP进程用户权限不足：/usr/sbin/sendmail需可执行，sendmail_path路径须正确且可访问，系统临时目录（如/tmp）需可写，SELinux/AppArmor策略可能拦截，须用实际运行用户模拟测试验证。
PHP 修改文件或目录权限本身不会直接影响 mail() 函数能否发邮件，但权限设置不当可能间接导致邮件发送失败——关键在于 PHP 进程能否访问邮件相关资源（如 sendmail 二进制、临时目录、配置文件）。
PHP mail() 发送失败时，哪些权限最常出问题
排查重点不是 PHP 脚本自身的读写权限，而是 PHP 运行用户（如 www-data、apache 或 nginx）是否具备调用系统邮件代理的权限：
-
/usr/sbin/sendmail（或/usr/bin/sendmail）必须对 PHP 进程用户可执行；若被设为700且属主非 PHP 用户，则调用失败 - PHP 的
sendmail_path配置指向的路径必须存在且可执行；常见错误是路径写错，或符号链接断裂（ls -l /usr/sbin/sendmail看是否指向真实二进制） -
sys_temp_dir（或系统默认临时目录如/tmp）需对 PHP 用户可写；否则邮件头解析、附件临时存储会失败，报错类似failed to open stream: Permission denied - 如果使用
ini_set('sendmail_path', ...)动态覆盖路径，该字符串里的命令及其依赖（如-t参数需要的 stdin 处理）也受权限约束
如何快速验证 sendmail 权限是否 OK
别只看 mail() 返回 true，它只表示“提交成功”，不保证实际投递。直接模拟 PHP 调用方式测试：
sudo -u www-data /usr/sbin/sendmail -t <<'EOF' To: test@example.com Subject: CLI Test This is a test. EOF
如果报 Permission denied 或 No such file or directory，说明权限或路径有问题。注意：sudo -u 必须用 PHP 实际运行的用户，不是 root 或当前登录用户。
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
立即学习“PHP免费学习笔记（深入）”；
- 若提示
command not found：检查sendmail_path配置值是否与which sendmail输出一致 - 若提示
cannot execute binary file：可能是架构不匹配（如 ARM 服务器装了 x86 sendmail），或 SELinux/AppArmor 拦截（见下一条） - 若静默无输出且收不到邮件：检查
/var/log/mail.log或journalctl -u postfix，确认 MTA 是否收到请求
SELinux / AppArmor 也会“假装是权限问题”
在 CentOS/RHEL（SELinux）或 Ubuntu（AppArmor）上，即使文件权限全开，安全模块仍可能阻止 Apache/Nginx 进程执行 sendmail。现象是：mail() 返回 false，日志里没有 sendmail 调用记录，audit.log 中出现 avc: denied。
- 临时验证：运行
setenforce 0（SELinux）或aa-disable /etc/apparmor.d/usr.sbin.apache2（Ubuntu），再试mail()；若恢复则确认是策略拦截 - 永久修复：不要关 SELinux，而是用
ausearch -m avc -ts recent | audit2why分析，然后用audit2allow生成新规则 - 常见布尔值：SELinux 下检查
httpd_can_sendmail是否为on（getsebool httpd_can_sendmail）
真正卡住人的往往不是 sendmail 权限本身，而是 PHP 进程用户和 MTA 用户之间的信任链断在哪一环——比如 Postfix 配置了 smtpd_relay_restrictions 拒绝本地未认证提交，或 Docker 容器里没挂载 /usr/sbin/sendmail。先确认 PHP 能否以对应用户身份手动跑通 sendmail，再查代码逻辑，比盲目改 chmod 777 有效得多。
