Cannot send test email - postdrop error: maildrop/ permission denied

Hello @ll,

my first post here - so point me at any communication mistakes…

I’m driving a self hosted gitea 1.18.5 at archlinux.

app.ini mailer section shows:
[mailer]
ENABLED = true
FROM = gitea@my.domain
MAILER_TYPE = sendmail
SENDMAIL_PATH = /usr/bin/sendmail
SENDMAIL_ARGS = “–”

sending test mail runs in timeout telling:
Failed to send a testing email to ‘me@my.mail.address’: gomail: could not send email 1: exit status 75

gitea logs don’t show suspicios things, but postfix/postdrop complains:

postfix/postdrop[3130]: warning: mail_queue_enter: create file maildrop/928929.3130: Permission denied

I tried several things:

  • sudo -u gitea sendmail -t me@my.mail.domain … # works - no postdrop message
  • sudo -u gitea touch /var/spool/postfix/maildrop/bla123 # works after adding user gitea to group postdrop

so sendmail is there and accessible by user gitea.
I suspect this is a permission problem, but I have no clue how to nail it down.
If You need more info, please ask.

Thanks in advance.

This is an aside to the issue, but the the mailer settings were tweaked slightly in 1.18.x to simplify things, but it looks like the docs were not updated. You should use PROTOCOL = sendmail instead of MAILER_TYPE = sendmail since MAILER_TYPE is deprecated and will eventually be removed. It won’t fix your problem though.

How are you running Gitea? If it’s a systemd service, can you post the contents of gitea.service?

1 Like

Here it is:

# cat /etc/systemd/system/multi-user.target.wants/gitea.service 
[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
After=mysqld.service
After=postgresql.service
After=memcached.service
After=redis.service

[Service]
User=gitea
Group=gitea
Type=simple
WorkingDirectory=~
RuntimeDirectory=gitea
LogsDirectory=gitea
StateDirectory=gitea
Environment=USER=gitea HOME=/var/lib/gitea GITEA_WORK_DIR=/var/lib/gitea
ExecStart=/usr/bin/gitea web -c /etc/gitea/app.ini
Restart=always
RestartSec=2s
ReadWritePaths=/etc/gitea/app.ini
AmbientCapabilities=
CapabilityBoundingSet=
LockPersonality=true
#Required by commit search
#MemoryDenyWriteExecute=true
NoNewPrivileges=true
#SecureBits=noroot-locked
PrivateDevices=true
PrivateTmp=true
PrivateUsers=true
ProtectClock=true
ProtectControlGroups=true
ProtectHome=true
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectProc=invisible
ProtectSystem=strict
RestrictAddressFamilies=AF_INET AF_INET6 AF_NETLINK AF_UNIX
RestrictNamespaces=true
RestrictRealtime=true
RestrictSUIDSGID=true
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

[Install]
WantedBy=multi-user.target

As @jake said, the configuration items have break changes. Please take a look at cheetsheet about mailer configurations.

I think issue is likely caused by some of the protection directives in gitea.service. Can you test running Gitea with a minimal service file like this? If this fixes issue, I would reintroduce the other directives one-by-one until issue is triggered to find out what directive caused issue.

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
After=mysqld.service
After=postgresql.service
After=memcached.service
After=redis.service

[Service]
User=gitea
Group=gitea
Type=simple
WorkingDirectory=~
Environment=USER=gitea HOME=/var/lib/gitea GITEA_WORK_DIR=/var/lib/gitea
ExecStart=/usr/bin/gitea web -c /etc/gitea/app.ini

[Install]
WantedBy=multi-user.target
1 Like

Indeed, this did the trick! :smile:

this was the culprit:

ProtectSystem=strict

Pointing me at gitea.service made me think of making some of the other protections less strict.

Thank You very much for Your helpful comments

2 Likes