When I initially configured Virtualmin (years ago) on this server, I set up ClamAV such that clamscan is running all the time (typically taking up around 1GB of 16GB RAM available). I assume it has been working since, as I’ve never seen errors in the maillog before now.
Recently when I was looking at the Procmail log (for another reason) I noticed the following error everywhere (one instance for every piece of email coming into the server):
ERROR: Could not connect to clamd on LocalSocket /run/clamd.scan/clamd.sock: Permission denied
I’m not sure when this began occurring, though most recently I have added SpamHaus upstream by using their DQS configuration and plugin for SpamAssassin (this is probably unrelated, but I mention it here as I do remember reading that they reconfigure SpamAssassin just a bit in order to improve filtering, and indeed my spam filtering was much improved after so doing).
I verified that the file in question (clamd.sock at the location above) does exist and has these permissions: srw-rw-rw- with group/owner as clamscan.
I don’t know what troubleshooting steps I should take next? The procmail log is so awash with these errors, I was so surprised! One error per email (even for the emails marked as Mode:Spam).
I ran freshclam and it said I was 1 version behind, so I updated it, seemingly successfully:
SelfCheck: Database modification detected. Forcing reload.
Reading databases from /var/lib/clamav
Database correctly reloaded (3627885 signatures)
Activating the newly loaded database...
I also tried restarting the clamscan process in case that might help:
Started clamd scanner (scan) daemon.
Image (graphics) scanning support enabled.
Detection using image fuzzy hash enabled.
AlertExceedsMax heuristic detection disabled.
Heuristic alerts enabled.
Portable Executable support enabled.
ELF support enabled.
Mail files support enabled.
OLE2 support enabled.
PDF support enabled.
SWF support enabled.
HTML support enabled.
XMLDOCS support enabled.
HWP3 support enabled.
OneNote support enabled.
Self checking every 600 seconds.
I looked at the posts linked to the replies above, but wasn’t really sure how to proceed further. I’m afraid I don’t know that much about how ClamAV works on my server.
Is there any way to query ClamAV to determine why it feels it doesn’t have permissions to use that .sock file (to which I’m pretty sure it does have permissions)? I hesitate to edit any configuration files, since they’re all just the ones made by Virtualmin out-of-the-box when I ran the installer on a fresh instance of Rocky Linux 9 in 2022 (having kept up-to-date with all package updates since then).
The owner of clamd.sock is clamscan:clamscan permission 0666 and it has 0 bytes changed the folder permission to 0755 and the error is gone.
I do see how this bit of advice might well help, but I am so nervous about making anything more permissive than it needs be, which is why I posted the permissions for /run/clamd.scan/clamd.sock in my original post srw-rw-rw- in case these were obviously incorrect.
I’m not sure honestly how to check this? I’ve always just assumed it was running fine in the past, since the ClamAV server status had a green checkmark next to it, and there were no errors in the maillogs. I’m not sure when these errors started as I can’t recall when I was last looking at the maillogs in detail. I’ve done the usual number of routine updates and reboots over the past month.
clamav-clamonacc is unrelated to email. clamd@scan is the scanner used for email.
And, your version is well after that specific packaging bug. I’ll have to pull up a Rocky 8 box and see if I can see what it’s supposed to be and maybe what went wrong on your system.
I appreciate your help! By the way, I’m on Rocky 9 (9.8 specifically).
In case it matters, I have a relatively out-of-the-box install other than that at some point in time, I followed the Virtualmin guide for installing multiple PHP versions, and thus set up REMI-safe as another repo.
EPEL is also enabled, though I seem to have an (unfortunately undocumented memory of mine) that I was careful at the time when enabling other package REPOs, ensuring that I only used them for whatever very few things were needed at the time.
And of course there are the Virtualmin package repos and all the defaults with Rocky 9. I keep everything up-to-date, and the system is running with plenty of RAM to spare (it’s usually using about 44% of 16GB, since I have some Ghost web app installs as well as Clam taking ~1GB).
@Armmiss Thanks for this, I had seen this post when I researched mine, but I was afraid that opening up permissions more wasn’t necessarily the right thing to do in this case. I try to keep permissions at their least permissive, and I try not to modify things on the server away from their defaults unless it’s absolutely essential.
I ended up doing something different, but you’re right that setting the permissions to 755 on every boot would have worked too, had I done that. Here’s what I did instead, after discussing this thread with an AI and also following up its recommendations on Stack Exchange threads for confirmation:
usermod -aG clamscan postfix
I then restarted Postfix (and also restarted ClamAV).
Here is the background that the AI gave me for going this route:
By adding postfix to the clamscan group instead of doing chmod 755, you’re following the principle of least privilege. With the existing 710 permissions, group members get the --x (traverse) right they need. Only the postfix user (and clamscan itself) can now traverse the directory. Everyone else is still blocked.
Indeed the errors about the socket connection permissions are now gone from the mail log!
Thanks for the information and for sharing this fix.
Unfortunately, this solution does not seem to work on RHEL 10.2.
I tried adding postfix to the clamscan group:
usermod -aG clamscan postfix
but it did not resolve the issue.
I also tried the workaround suggested by AI:
usermod -aG virusgroup postfix
but this did not work either.
After spending more than two hours investigating the issue with the help of AI, the workaround I found that seems to be the “least dirty” solution is to add a systemd override:
With this change, the permissions are adjusted automatically after the clamd service starts, and the issue is worked around without manually changing permissions after every restart.
Hopefully this can help other users running RHEL 10.2, and perhaps a more appropriate fix can be found in the future.
