AppArmor complaints would be shown in journalctl too. But dmseg doesn't show anything either. Just switched dovecot back to these log files, waited for the error message, yet dmesg doesn't have anything new since yesterday. Systemd was also my guess as it was originally set to ProtectSystem=full for dovecot.service, but reducing that to yes didn't change anything.
These are the in the Service block of the service, maybe you see anything that could be a reason too: [Service] Type=notify ExecStart=/usr/sbin/dovecot -F ExecReload=/usr/bin/doveadm reload ExecStop=/usr/bin/doveadm stop PrivateTmp=true NonBlocking=yes ProtectSystem=yes ProtectHome=no PrivateDevices=true Restart=on-failure Best Richard Am Mo., 13. Mai 2024 um 22:28 Uhr schrieb Greg Wooledge <g...@wooledge.org>: > On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote: > > May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=< > u...@domain.de>, > > > relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, > status=deferred > > > (temporary failure. Command output: lda(user): Error: > > > net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied > Can't > > > open log file /var/log/dovecot/error.log: Permission denied ) > > > > This is the content of /var/log/dovecot: > > -rw-r--r-- 1 dovecot dovecot 0 13. Mai 20:50 debug.log > > -rw-r--r-- 1 dovecot dovecot 880 13. Mai 21:21 error.log > > -rw-r--r-- 1 dovecot dovecot 40K 13. Mai 21:20 info.log > > The first two things that come to mind are AppArmor, and systemd unit > files. > > Check to see whether there's an AppArmor profile for this program, or > any lines from AppArmor in dmesg. > > If that's not it, look at the systemd unit file(s) that start the > dovecot service(s), if there are any, and see if they're using any of > the directives that restrict the locations the program can access. > >
