1 (edited by mir 2014-11-26 01:09:09)

Topic: backup not performed

==== Required information ====
- iRedMail version: 0.8.7
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): LDAP
- Linux/BSD distribution name and version: Debian Stable
- Related log if you're reporting an issue:
====
For reason unknown to me crontab files for root and amavis was created with wrong permission causing backup and other scheduled things not happening.

Starting cron gave the following output to syslog:
Nov 25 17:36:40 iredmail /usr/sbin/cron[12152]: (amavis) INSECURE MODE (mode 0600 expected) (crontabs/amavis)
Nov 25 17:38:10 iredmail /usr/sbin/cron[12290]: (root) INSECURE MODE (mode 0600 expected) (crontabs/root)

-rw-r--r-- 1 root root 290 Apr  7  2014 /var/spool/cron/crontabs/amavis
-rw-r--r-- 1 root root 579 Apr  7  2014 /var/spool/cron/crontabs/root

Doing below statements fixed the issue:
sudo chmod 600 /var/spool/cron/crontabs/amavis
sudo chmod 600 /var/spool/cron/crontabs/root

service cron restart

PS. My current install started as 0.8.6 and since the backup folder is empty this bug has been there from at least 0.8.6

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: backup not performed

*) Improper file permission was fixes in development version of iRedMail yesterday.
*) I don't think improper file permission causes cron job was not executed, it might be caused by one known bug of crontab. It's mentioned in crontab(5):

# man 5 crontab
...
DIAGNOSTICS
       cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing  a
       newline  (ie,  terminated  by  EOF),  cron will consider the crontab (at least partially) broken. A warning will be
       written to syslog.
...

3

Re: backup not performed

ZhangHuangbin wrote:

*) Improper file permission was fixes in development version of iRedMail yesterday.
*) I don't think improper file permission causes cron job was not executed, it might be caused by one known bug of crontab. It's mentioned in crontab(5):

# man 5 crontab
...
DIAGNOSTICS
       cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing  a
       newline  (ie,  terminated  by  EOF),  cron will consider the crontab (at least partially) broken. A warning will be
       written to syslog.
...

I am aware of the EOF bug and this is not the issue since the crontab file has the proper EOL. The issue I reported does have an impact since a crontab without proper permissions will be disregarded from cron execution because after applying proper permissions updates started to be made automatically without other intervention.

4

Re: backup not performed

Oh, then it's iRedMail issue (not set proper file permission).

BTW, looks like cron job with default file permission created by iRedMail works on other linux/bsd distributions.