malware acl condition: clamd: ClamAV returned /var/spool/exim4/scan/XXXX.eml: Can't create temporary directory ERROR
Hello, I am successfully using exim4u for some time. Thanks Gordon for your work! Now I installed exim4u 1.2.5 on another server with only relay-domains configured so far. From time to time I see the following error in /var/log/exim4/paniclog: 2011-02-15 22:20:42 XXXX malware acl condition: clamd: ClamAV returned /var/spool/exim4/scan/XXXX/XXXX.eml: Can't create temporary directory ERROR exim4u is running on Debian squeeze. I think I make all the necessary adoptions concerning paths and usernames/groups. I also added the clamav user to the Debian-exim group. clamd runs as clamav user: $ps axu | grep clamd clamav 15173 0.3 19.4 125480 102016 ? Ssl Feb13 21:54 /usr/sbin/clamd Interestingly it does not happen with all relayed mails, but only with a few. Do you have any hints where the problem might be? Best regards, Udo
On 02/17/2011 05:04 AM, Udo Hortian wrote:
From time to time I see the following error in /var/log/exim4/paniclog:
2011-02-15 22:20:42 XXXX malware acl condition: clamd: ClamAV returned /var/spool/exim4/scan/XXXX/XXXX.eml: Can't create temporary directory ERROR
Hi Udo, That is quite strange especially since it only occurs sometimes. I can't say for sure but I suspect that this is most probably a ClamAV problem. Check to see if the clamd logs have any related entries that might yield a clue. I realize this is obvious but make sure that the Debian-exim user and clamav user both have read/write permission to the /var/spool/exim4/scan directory. It sounds like everything is running fine until some unusual convergence of events occur. I would also examine your clamd configuration file (/etc/clamd.conf). There are several parameters in clamd.conf that specify maximum allowable values such as MaxConnectionQueueLength, StreamMaxLength and MaxThreads. This mailing list post is for a similar situation: http://lists.exim.org/lurker/message/20050414.060700.734834f7.en.html The above link suggested that the user uncoment or add in the clamd.conf file: AllowSupplementaryGroups I also found this post for the exact same situation as you have encountered: http://www.directadmin.com/forum/showthread.php?t=30992 However, it did not offer a solution except for the following: "Changed some exim and clamd settings and voila my problem seems solved!" I checked the logs on my servers and have not yet seen this error message, however, I will continue to watch my logs closely especially for my relay domains. Let me know what you find when you figure it out. Gordon
Hello Gordon, On Fri, Feb 18, 2011 at 10:07:31AM -0500, Gordon Dickens wrote:
That is quite strange especially since it only occurs sometimes. I can't say for sure but I suspect that this is most probably a ClamAV problem. Check to see if the clamd logs have any related entries that might yield a clue. I checked the clamav.log and when the error occurs I find lines like:
Tue Feb 15 22:20:42 2011 -> /var/spool/exim4/scan/XXXX/XXXX.eml: Can't create temporary directory ERROR Just like in exim's paniclog.
I realize this is obvious but make sure that the Debian-exim user and clamav user both have read/write permission to the /var/spool/exim4/scan directory. In fact the permissions to this directory are as follows:
ls -l /var/spool/exim4/ | grep scan drwxr-x--- 2 Debian-exim Debian-exim 4096 Feb 18 12:54 scan Before I checked this, but somehow was not noting the missing w for the group. So the Debian-exim group has NO write-permission. On another system running exim4u (which I use as the primary MX) the permissions are identical and I do not have any errors of this kind there. Probably here lies the problem. But since I do not have any problems on the other system, I would like to understand first, why I really need write access here. How does virus scanning actually works? Which process really needs access to this directory? Then I would like to understand why there are no problems on my other system.
It sounds like everything is running fine until some unusual convergence of events occur. I would also examine your clamd configuration file (/etc/clamd.conf). There are several parameters in clamd.conf that specify maximum allowable values such as MaxConnectionQueueLength, StreamMaxLength and MaxThreads.
This mailing list post is for a similar situation:
http://lists.exim.org/lurker/message/20050414.060700.734834f7.en.html
The above link suggested that the user uncoment or add in the clamd.conf file: AllowSupplementaryGroups As far as I understand for this to take effect, one must run clamd as root.
I also found this post for the exact same situation as you have encountered:
http://www.directadmin.com/forum/showthread.php?t=30992
However, it did not offer a solution except for the following: "Changed some exim and clamd settings and voila my problem seems solved!" Yeah, not really helpful.
I checked the logs on my servers and have not yet seen this error message, however, I will continue to watch my logs closely especially for my relay domains. Thank you!
Best, Udo
On Fri, Feb 18, 2011 at 6:52 PM, Udo Hortian <udo_hortian(a)web.de> wrote:
Hello Gordon,
On Fri, Feb 18, 2011 at 10:07:31AM -0500, Gordon Dickens wrote:
That is quite strange especially since it only occurs sometimes. I can't say for sure but I suspect that this is most probably a ClamAV problem. Check to see if the clamd logs have any related entries that might yield a clue. I checked the clamav.log and when the error occurs I find lines like:
Tue Feb 15 22:20:42 2011 -> /var/spool/exim4/scan/XXXX/XXXX.eml: Can't create temporary directory ERROR
Just like in exim's paniclog.
I realize this is obvious but make sure that the Debian-exim user and clamav user both have read/write permission to the /var/spool/exim4/scan directory. In fact the permissions to this directory are as follows:
ls -l /var/spool/exim4/ | grep scan drwxr-x--- 2 Debian-exim Debian-exim 4096 Feb 18 12:54 scan
Before I checked this, but somehow was not noting the missing w for the group.
So the Debian-exim group has NO write-permission. On another system running exim4u (which I use as the primary MX) the permissions are identical and I do not have any errors of this kind there.
Probably here lies the problem. But since I do not have any problems on the other system, I would like to understand first, why I really need write access here. How does virus scanning actually works? Which process really needs access to this directory?
Then I would like to understand why there are no problems on my other system.
Things to check::: I run clamd as mailnull (the same user Exim runs as). Afterall, they both process the same mail. (20:20:25 <~>) 0 $ grep User /usr/local/etc/clamd.conf User mailnull (20:20:35 <~>) 0 $ exim -bP | grep exim_user exim_user = mailnull (20:20:49 <~>) 0 $ (20:20:49 <~>) 0 $ ls -al /var/spool/exim/ total 24 drwxr-x--- 7 mailnull mailnull 512 Oct 26 2009 . drwxr-xr-x 15 root wheel 512 Dec 27 15:17 .. drwxr-x--- 2 mailnull mailnull 512 Feb 18 18:18 db drwxr-x--- 13 mailnull mailnull 7680 Feb 18 20:13 input drwxr-x--- 2 mailnull mailnull 512 Oct 26 2009 log drwxr-x--- 17 mailnull mailnull 4096 Feb 18 20:13 msglog drwxr-x--- 3 mailnull mailnull 512 Feb 18 20:13 scan (20:21:16 <~>) 0 $ In clamd.conf: TemporaryDirectory /var/tmp -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Damn!!
On 02/18/2011 12:24 PM, Odhiambo Washington wrote:
I run clamd as mailnull (the same user Exim runs as). Afterall, they both process the same mail.
Odhiambo may be onto something here. I also run clamd and exim as the same user in my installations (eg.: I run exim and clamd as user=exim in CentOS). So, consider giving that a try. For example with Debian, try having clamd run as the Debian-exim user same as exim. Gordon
participants (3)
-
Gordon Dickens -
Odhiambo Washington -
Udo Hortian