/tmp filled with clamav files --> user over quota
 

When user arno@domain.tld tries to send an e-mail to admin@domain.tld it bounces back with the following error:

== Bounce ==

<web7_admin@server1.example.com> (expanded from <admin@domain.tld>):
can't create user output file. Command output: procmail: Quota exceeded
while writing
"/var/www/web7/Maildir/tmp/1179487840.31842_0.server1.example.com"


And in the maillogs:

== mail.log ==

May 18 13:30:38 h1266987 postfix/smtpd[31837]: C7FBD1FC0E6E: client=client.bla.com[x.x.x.x], sasl_method=LOGIN, sasl_username=web7_arno
May 18 13:30:38 h1266987 postfix/cleanup[31840]: C7FBD1FC0E6E: message-id=<BLEKKFFIOFKCHJJFFGHEGEPPCAAA.arno@domain.tld>
May 18 13:30:38 h1266987 postfix/qmgr[22332]: C7FBD1FC0E6E: from=<arno@domain.tld>, size=749, nrcpt=1 (queue active)
May 18 13:30:41 h1266987 postfix/local[31841]: C7FBD1FC0E6E: to=<web7_admin@server1.example.com>, orig_to=<admin@domain.tld>, relay=local, delay=3, status=bounced (can't create user output file. Command output: procmail: Quota exceeded while writing "/var/www/web7/Maildir/tmp/1179487840.31842_0.server1.example.com" )
May 18 13:30:41 h1266987 postfix/qmgr[22332]: C7FBD1FC0E6E: removed


The web7_admin user has a qouta limit of 25 MB. Repquota shows the user has reached its limit:

h1266987:/var/log# repquota -avug | grep web7
web7_admin -- 25600 25600 26624 none 244 0 0


However the directory for his mail and logs only contains around 11 MB (/var/www/web7/user/web7_admin/). I found out the rest is in the /tmp directory:

h1266987:/var/log# ll /tmp/
total 8
drwx------ 2 web7_admin web7 4096 May 18 13:30 clamav-861a09f2850a263a1e290c829169e102

h1266987:/tmp# ll /tmp/clamav-861a09f2850a263a1e290c829169e102/
total 13676
-rw------- 1 web7_admin web7 17992 May 18 13:30 COPYING
-rw------- 1 web7_admin web7 4736232 May 18 13:30 main.db
-rw------- 1 web7_admin web7 637507 May 18 13:30 main.hdb
-rw------- 1 web7_admin web7 8572928 May 18 13:30 main.ndb


I'm not sure, but the problem seems to be related to the problem described in thread 11100. However, the ISPConfig version is 2.2.12 and Clamav version is 0.90.2. It seems the user is invoking the clamav update by sending an e-mail, but the update fails.What may be causing this problem?

Grtz,
Arno.

Are you sure the ISPConfig version is 2.2.12? Because this problem was fixed in one of the last releases...

Which linux distribution do you use? Are the clamav database files and directory world readable? Otherwise the access from the clamassassin script will fail and clamav tries to download the database files again.

@Falko: Yes the version is 2.2.12. What did you do to fix it?

@Till: The distro is debian sarge and all the clamav files and dir's are world readable. Probably a shot in the dark but the server is a Virtuoso-based VPS.

Till implemented the fix, so I'm not sure...

It probably has something to do with this: http://lists.jameslick.com/pipermail...ry/000030.html. It says to remove the --mbox option from the CLAMSCANOPT variable.

# Configure options passed to clamscanner
CLAMSCANOPT="--no-summary --stdout"

Till mentioned it in his thread: http://www.howtoforge.com/forums/sho...t=clamassassin.

I wonder if it is possible to run the updates as the admispconfig user or some other user without a quota?

Grtz,
Arno

These fixes are all applied in ISPConfig 2.2.12, but you may check the files yourself.

Thats not a quota problem of the quota during updates. The updates are always run by a user without quota. The problem is that clamav seems to refuse the updated databases on your server and then loads a new database under the owner of the mailbox.

I use ISPConfig 2.2.12 under sarge here too and I dont get any tmp files from clamav.

The files are ok :)

Do you have any idea why clamav refuses it? The funny thing is it doesn't happen all the time. Most of the time the update completes succesfully, so I figured it can't be the clamav database being corrupt.

As a workaround I increased the quota for the user. It isn't life-threatening after all :D ..

Tnx for your help.

Grtz,
Arno.

I have no idea. Maybe you can try to turn on logging for Clamav. The complete clamav installation that ISPConfig uses is in /home/admispconfig/ispconfig/tools/clamav

There is one workaround that you might try.

1) Install clamd (the daemon version) from your linux distribution.
2) Reconfigure the ISPConfig clamassassin script in /home/admispconfig/ispconfig/tools/clamasassin to use the clamd daemon instaed of the clamav binary from ISPConfig.

I am having the same problem on the 2.2.12 version. I just deleted the files from /tmp as a temporary measure. I hope this was the correct thing to do.