Debian 8 – How to fix amvavis reporting “permission denied” for clamav

I’ve recently noticed a frustrating niggle… When processing email, an Ubuntu Server (with all the updates applied) reports “Permission denied” when trying to virus scan attachments.

Apr  2 14:05:20 svr amavis[6376]: (06376-01) (!)run_av (ClamAV-clamd) FAILED - unexpected , output="/var/lib/amavis/tmp/amavis-20150402T140519-06376-PZcyHfOt/parts: lstat() failed: Permission denied. ERROR\n"
Apr  2 14:05:20 svr amavis[6376]: (06376-01) (!)ClamAV-clamd av-scanner FAILED: CODE(0x30cf250) unexpected , output="/var/lib/amavis/tmp/amavis-20150402T140519-06376-PZcyHfOt/parts: lstat() failed: Permission denied. ERROR\n" at (eval 136) line 899.
Apr  2 14:05:20 svr amavis[6376]: (06376-01) (!)WARN: all primary virus scanners failed, considering backups

When I look at the directories in question, I see this:

$ ls -ld /var/lib/amavis/tmp
drwxrwx--- 4 amavis amavis 4096 Apr  2 14:16 /var/lib/amavis/tmp
$ ls -ld /var/lib/amavis/tmp/amavis-20150402T140519-06376-PZcyHfOt/
drwxr-x--- 3 amavis amavis 4096 Apr  2 14:05 /var/lib/amavis/tmp/amavis-20150402T140519-06376-PZcyHfOt/
$ ls -ld /var/lib/amavis/tmp/amavis-20150402T140519-06376-PZcyHfOt/parts                                                                                                                                                                           
drwxr-x--- 2 amavis amavis 4096 Apr  2 14:16 /var/lib/amavis/tmp/amavis-20150402T140519-06376-PZcyHfOt/parts

I made sure the clamd user is a member of the amavisd group – but this didn’t fix anything. Can anyone tell me, specifically, which component wants what permissions – and… ideally… what to do to fix this?

Clarification: I am not looking an explanations of the fundamentals of permissions. I am looking for a solution appropriate to this specific problem – which, at first glance, at least, looks as if a component of the amavis suite (perhaps clamd) is using the wrong umask value. Of course, this fault may have arisen as a result of a number of bugs or configuration glitches. I am looking, specifically, for the most appropriate resolution for this case… where a ‘vanilla’ amavis/clamav install fails to access the contents of temporary folders it creates as/when required to scan inbound email.

I am aware of this similar (non-Ubuntu) question. The Redhat/Centos answer doesn’t solve the problem I experience with Ubuntu.

This problem is encountered on “Ubuntu 14.04.2 LTS” – there are no pending updates.

shareimprove this question
The group amavis has no write permissions for /var/lib/amavis/tmp/amavis-20150402T140519-06376-PZcyHfOt/ and /var/lib/amavis/tmp/amavis-20150402T140519-06376-PZcyHfOt/pa‌​rts – A.B. Apr 2 ’15 at 14:31
Try this chmod -R g+w /var/lib/amavis/tmp – A.B. Apr 2 ’15 at 14:35
The problem isn’t that I can’t change the permissions to permit group write on the directories… The problem is that I don’t know how to ensure that directories created under /var/lib/amavis/tmp/ – in future – get created with the correct permissions. This directory seems to be where amavis expands messages to inspect attachments. The defaults used to work… now, after some updates, it doesn’t. – aSteve Apr 2 ’15 at 20:57
Then work on your question. – A.B. Apr 4 ’15 at 9:43

4 Answers

A working solution is to change

AllowSupplementaryGroups false -> true

in /etc/clamav/clamd.conf

restart clamav-daemon

shareimprove this answer
2
This is what solved it for me (I’m on Debian Jessie). Adding clamav to the amavis group didn’t solve it. – chmike Feb 6 ’16 at 16:27
The AllowSupplementaryGroups option has been dropped in recent versions of clamav (0.99.2+, Jun 2, 2016 in upstream). – Daniel Vérité Aug 31 ’16 at 2:35
+1 This worked. The approved answer below DOES NOT. If you followed the Ubuntu AmavisNew wiki page (hopefully), you would have already added amavis/clamav as supplementary groups to one another. Approved answer does nothing but repeat this – and does not work. I am running default pkgs on 16.04.1 LTS. ref: help.ubuntu.com/community/PostfixAmavisNew – bshea Feb 16 at 17:46

While the clamd user was a member of the amavis group, the clamd process was running as the clamav (not clamd) user.

Adding clamav to the amavis group solved the issue.

shareimprove this answer

As AllowSupplementaryGroups does not exist anymore, I ended by adding each user to the other group, like this:

usermod -a -G clamav amavis
usermod -a -G amavis clamav

(and restart everything just to be sure)

/etc/init.d/clamav-daemon restart
/etc/init.d/amavis restart
/etc/init.d/postfix restart

With this, no need to change folder permission on /var/lib/amavis/tmp (and I’m not sure those permissions will be left as is on the next apt-get upgrade…)

shareimprove this answer