[RÉSOLU] Mail services (dovecot, slapd, postfix) bug after reinstall from backup without postinstall

Support Installation
, ,
1

Some time ago I restored my internet cube by :

  1. Flashing the image
  2. Not runnning the postinstall
  3. Applying a backup
    See this post for details
    [Résolu] Restauration ou Migration de yunohost sur DD / [Solved] Restore or Migrate yunohost on a HDD
    Since then, I noticed some instability. I looked into the syslog and saw lots of errors related to
  • dovecot (Error: chdir(/var/mail/USER/) failed: Permission denied (euid=500(vmail) egid=8(mail) missing +x perm: /var/mail/USER, dir owned$),
  • slapd (slapd[842]: <= mdb_equality_candidates: (virtualdomain) not indexed),
  • postfix (postfix/pipe[28912]: 5DFAA3A45AC: to=USER@DOMAIN, orig_to=, relay=dovecot, delay=2.3, delays=0.99/0.07/0/1.3, dsn=4.3.0, status=deferred (temporary failure)).

Moreover in the monitoring app netdata, section applications, I see that the email app is running permanently and using most of the CPU.

I think I might have excluded mails from the backup I used. Thus I guess I’d have to run the postinstall for the related services.
Is there a way to reinstall/reconfigure the services related to email without running the postinstall? Or if I run the postinstall after restore, is there a risk to break the configuration of other services that were correctly setup by the restore (dnsmask, vpnclient,…)?

2

Disclaimer: I’m not familiar with the backup/restore process.

Dovecot complains about wrong permissions in /var/mail.
Can you find a way to compare the content of this directory with its content from the original yunohost instance?

For comparison here is what I have on my cube (only two users, ‘toto’ and ‘tata’):

# ls -l /var/mail/
drwx--S---  2 vmail mail 4096 juin  20 15:41 tata
drwx--S--- 10 vmail mail 4096 juin  20 11:17 toto

# ls -l /var/mail/toto
drwx--S--- 2 vmail mail 4096 juin  20 11:16 cur
-rw------- 1 vmail mail  396 juin  20 11:17 dovecot.index.log
-rw------- 1 vmail mail  120 juin  20 11:16 dovecot.mailbox.log
-rw------- 1 vmail mail   51 juin  20 11:17 dovecot-uidlist
-rw------- 1 vmail mail    8 juin  20 11:16 dovecot-uidvalidity
-r--r--r-- 1 vmail mail    0 juin  20 11:16 dovecot-uidvalidity.5b2a1b8a
-rw------- 1 vmail mail    7 juin  20 11:16 maildirsize
drwx--S--- 2 vmail mail 4096 juin  20 11:16 new
-rw------- 1 vmail mail   31 juin  20 11:16 subscriptions
drwx--S--- 2 vmail mail 4096 juin  20 11:16 tmp

Maybe the restore process did not set the correct owner/group names.
You may fix this manually:

sudo chown -R vmail:mail /var/mail/

PS: you can safely ignore all the warnings from slapd (mdb_equality_candidates… not indexed)

2 Likes
3

I had updated the restore hook to be sure permissions are ok:

1 Like
4

My main user had indeed bad permissions dating from 1970

chown -R vmail:mail /var/mail/ did the trick!

Now, in the monitoring app netdata, section applications, I see that the fail2ban app is running permanently and using most one CPU core full time.

5

Maybe you have a huge log file being scanned by fail2ban. The problem is already described and solved in topic #2439.

If your problem is something different then don’t reply here. Since the issue concerning mail services seems to be solved please open a new topic instead to keep things organised.