I tend to switch Linux distributions quite often. Consequently, I tend to have this process down to a fine art and it doesnt take me that long. The most time consuming element is ensuring the necessary backups are in place.
However, you normally find some package or configuration option you forgot about and my recent switch from Arch Linux to Fedora 29 and back again unearthed a strange problem with the Dovecot IMAP server I hadn't encountered before.
When I accessed my email, my automatic message filtering (using sieve) wasn't working so all messages ended up in INBOX. Worse, on every transfer, the messages were duplicated.
The logging revealed a strange error related to file permissions
$ journalctl | grep dovecot
Nov 29 08:45:32 <host> CROND[3356]: (andy) CMDOUT (msg 53/60 (12176 bytes),
delivery error (command dovecot-lda 3415 wrote to stderr: lda(andy,)
Error: net_connect_unix(/var/run/dovecot/stats-writer) failed:
Permission denied))
The permissions on this socket file were as follows:
$ ls -l /var/run/dovecot/stats-writer
srw-rw---- 1 root dovecot 0 Nov 29 08:52 /var/run/dovecot/stats-writer
Google revealed a couple of fixes. One was to simply change the permissions on the socket file to mode 777 which works for the duration of that session but the problem simply reappears after the next reboot.
Another, more promising avenue was to add a new section to '/etc/dovecot.conf'.
service stats {
...
}
I tried a couple of combinations which didn't work but then I went back to basics. I am processing my email as 'andy' but the dovecot processes are running as 'root' and' 'dovecot' (although they could be SETUID executables).
root 8276 1 0 11:45 ? 00:00:00 /usr/bin/dovecot -F
dovecot 8278 8276 0 11:45 ? 00:00:00 dovecot/anvil
root 8279 8276 0 11:45 ? 00:00:00 dovecot/log
root 8280 8276 0 11:45 ? 00:00:00 dovecot/config
However, I wondered if Local Delivery Agent (LDA) was somehow running as 'andy' (the error log implied this) which explained the permissions issue as the Linux user 'andy' isn't able to read that socket file.
Sure enough, the fix, inevitably, was a simple one-liner to add user 'andy' to the existing 'dovecot' group.
sudo usermod -a -G dovecot andy