Permissions issue accessing spool file when sending emails #97
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Using OTP release 2.5.0 on Debian 11 (bullseye)
Mailer configured with Sendmail using exim4 4.94.2
I am unable to get Pleroma to send any emails successfully. Password resets for example do not work.
When I run
pleroma_ctl email test --to my@email.com, a success message is printed, but no email actually goes out, and no logs appear in/var/log/exim4. However, I do see the following journalctl entry logged several times for each attempt:Jan 02 23:25:01 localhost pleroma[507382]: 2023-01-02 23:25:01 1pCUAv-0027za-OH Failed to create spool file /var/spool/exim4//input//1pCUAv-0027za-OH-D: Permission deniedThis seems like maybe something funky going on with my system, and not an actual issue with Pleroma. Although I will point out that emails do send successfully when I run
su pleroma sendmail my@email.com < test-email.txt.Here's my mailer config:
config :pleroma, Pleroma.Emails.Mailer, [ adapter: Swoosh.Adapters.Sendmail, cmd_path: "/usr/sbin/sendmail", enabled: true, cmd_args: ""]I think this might have to do with the service configuration of pleroma (systemd or OpenRC). Like I think NoNewPrivs is the culprit as the
sendmailcommand is sometimes setuid/setgid.I did see something like that in one of the previous issues. I'm using systemd. But I wasn't sure if that was still an issue since it looked like it had been addressed in this PR: pleroma/pleroma#6480
In any case, I found two
pleroma.servicefiles, in/ect/systemd/systemand in/etc/systemd/system/multi-user.target.wants. The first one hadNoNewPrivileges=falsealready, but the other one was true. Still, after changing that, the issue persists. Maybe there's another that I'm missing...I have an update to this!
At first I thought maybe the issue was my email agent, exim4, so I tried switching to postfix. That had no effect, it just changed the error messages in
journalctlslightly (and made a lot more of them appear).I wasn't able to find any other service files, but I did mess around with some of the settings and, in addition to the aforementioned
NoNewPrivilegessetting, I found this one which seemed to be causing trouble:PrivateDevices=trueAfter commenting it out, the test emails started going out successfully. Password reset emails also go out now.
To be honest, I'm not sure what the security implications of disabling this setting are, but thought I'd share my workaround in case anyone else is struggling with it.