Postfix: newaliases fails at postfix service startup due to aliases.db permission problems

I recently started migrating my mail server to systemd.

I have an alias hash map:

alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases

When starting the service:

systemctl restart postfix

newalias and postalias complain about the permissions of my aliases.db whatever permissions I set:

● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2020-07-22 00:36:08 CEST; 22ms ago
    Process: 299515 ExecStartPre=/usr/bin/newaliases (code=exited, status=1/FAILURE)
    Process: 299518 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
   Main PID: 299596 (master)
        CPU: 721ms
     CGroup: /system.slice/postfix.service
             ├─299596 /usr/libexec/postfix/master -w
             ├─299597 pickup -l -t unix -u
             └─299598 qmgr -l -t unix -u

jul 22 00:36:07 rulakir systemd[1]: Starting Postfix Mail Transport Agent...
jul 22 00:36:07 rulakir newaliases[299515]: postalias: fatal: open /etc/postfix/aliases.db: Read-only file system
jul 22 00:36:07 rulakir postfix/postalias[299515]: fatal: open /etc/postfix/aliases.db: Read-only file system
jul 22 00:36:08 rulakir postfix/postfix-script[299582]: warning: group or other writable: /etc/postfix/./aliases.db
jul 22 00:36:08 rulakir postfix/postfix-script[299594]: starting the Postfix mail system
jul 22 00:36:08 rulakir postfix/master[299596]: daemon started -- version 3.5.1, configuration /etc/postfix
jul 22 00:36:08 rulakir systemd[1]: Started Postfix Mail Transport Agent.

It complains that it read only, but if I change group or owner to postfix it complains that it should be owned by root and/or that it has write permissions. What permissions should I give to aliases and aliases.db?

Server Fault Asked by Jens Björnhager on November 14, 2021

1 Answers

One Answer

The Gentoo mail-mta/postfix package's systemd service unit includes hardening options by default which do indeed sandbox the service. Specifically:


Despite the additional sandboxing, the /etc/mail/aliases.db file should be writable thanks to the ReadWritePaths. From the systemd.exec man page:


Takes a boolean argument or the special values "full" or "strict". <...> If set to "full", the /etc directory is mounted read-only, too.


Paths listed in ReadWritePaths= are accessible from within the namespace with the same access modes as from outside of it.

Paths in ReadWritePaths=, ReadOnlyPaths= and InaccessiblePaths= may be prefixed with "-", in which case they will be ignored when they do not exist.

Based on the latest stable mail-mta/postfix ebuild (3.5.1) as of this writing, src_prepare includes sed -i -e "/^#define ALIAS_DB_MAP/s|:/etc/aliases|:/etc/mail/aliases|" to set the default location of the alias map at the appropriate location. Yet from your logs, yours seem to point to /etc/postfix/aliases.db. I'd suggest leaving the default of /etc/mail/aliases.db or overriding the ReadWritePaths using systemctl edit postfix.service appropriately.

Answered by Ginnungagap on November 14, 2021

Add your own answers!

Related Questions

On demand new IPv6 using privacy extension?

1  Asked on December 12, 2020 by wannabecoder


nginx, gitlab, subdomain

1  Asked on December 10, 2020 by emidee


Move Access 2016 Database to Azure?

0  Asked on December 9, 2020 by user601108


NGINX/GemInABox – static links aren’t properly passed

0  Asked on December 8, 2020 by anotherclueless


How do I start & stop my AKS cluster?

2  Asked on December 8, 2020 by sarabpreet-singh


Nginx rewrite: replace – with /

2  Asked on December 7, 2020 by tomas-morgan


SCCM Application Deployment – No Status or Errors

1  Asked on December 6, 2020 by jshizzle


Centos 7 Sofia-sip dependency for Janus sip gateway

2  Asked on December 6, 2020 by dmitriy-povolotskiy


Switching NICs in VPN tunnel

0  Asked on December 6, 2020 by kubek


Ask a Question

Get help from others!

© 2021 All rights reserved.