How to Create ClamAV on Linux Server in 2026 – (Step by Step Guide)

To create ClamAV on a Linux server, install the ClamAV engine and FreshClam updater, enable the clamd daemon, update the signature databases, and schedule recurring scans.

Use clamscan for one-off checks, clamdscan for faster daemon-based scans, and clamonacc for real-time (on-access) protection via fanotify with well-tuned exclusions.

Setting up ClamAV on a Linux server is one of the simplest, most cost-effective ways to detect malware, web shells, and suspicious files.

In this guide, I’ll show you exactly how to install, configure, and optimize ClamAV on Ubuntu/Debian and RHEL/AlmaLinux/CentOS, including real time scanning, schedules, performance tuning, and best practices I use on production servers.

What is ClamAV and Why Use it on a Linux Server?

ClamAV is an open-source antivirus engine for detecting trojans, malware, and malicious scripts. It’s widely used on web, mail, and file servers to scan uploads, email attachments, and backups. While no antivirus replaces secure coding and patching, ClamAV adds a vital layer of defense and visibility for your Linux stack.

Prerequisites and Planning

Before you start, confirm root or sudo access, outbound internet for signature updates, and at least 1–2 GB RAM for comfortable scanning. Plan exclusions (e.g., system directories, caches, large archives) and decide if you need real-time scanning or scheduled scans only.

Install ClamAV on Ubuntu/Debian

On Debian-based systems, you’ll install the engine, updater, and optionally the daemon for faster scans.

sudo apt update
sudo apt install -y clamav clamav-daemon

# Stop services before first DB update to avoid lock contention
sudo systemctl stop clamav-freshclam || true
sudo systemctl stop clamav-daemon || true

# Initial signature update (can take a few minutes)
sudo freshclam

# Start services
sudo systemctl enable --now clamav-freshclam
sudo systemctl enable --now clamav-daemon

# Verify
clamscan --version
systemctl status clamav-daemon

Install ClamAV on RHEL/AlmaLinux/CentOS

On RPM-based systems, use dnf or yum. Names vary slightly across releases.

sudo dnf install -y epel-release
sudo dnf install -y clamav clamav-update clamav-scanner clamav-server-systemd

# Stop services before the first update (if present)
sudo systemctl stop clamav-freshclam 2>/dev/null || true
sudo systemctl stop clamd@scan 2>/dev/null || true

# Fresh signatures
sudo freshclam

# Enable and start
sudo systemctl enable --now clamav-freshclam
sudo systemctl enable --now clamd@scan

# Verify
clamscan --version
systemctl status clamd@scan

Update Signatures with FreshClam

FreshClam keeps your detection current. It runs as a service by default and checks multiple times daily. When troubleshooting, run it manually to confirm connectivity.

sudo freshclam
# Logs often live here:
sudo tail -n 50 /var/log/clamav/freshclam.log

Daemon vs One-Off Scans: Which Should You Use?

ClamAV supports two scan modes. Choose based on your workload.

• clamscan (standalone): Loads signatures into memory each run. Good for occasional scans, lower memory persistence, but slower per scan.
• clamdscan (daemon): Uses the clamd service with signatures preloaded. Much faster per scan, ideal for servers scanning frequently or in production.

# Example: one-off scan (recursive) with a report
sudo clamscan -ri /var/www > /var/log/clamav/www-scan.log

# Example: daemon-backed scan (faster)
sudo clamdscan --fdpass --multiscan /var/www

Core Configuration: clamd.conf and freshclam.conf

Default configs work for most servers. For tighter control, tune paths, exclusions, and performance. Typical locations are /etc/clamav/clamd.conf and /etc/clamav/freshclam.conf (Debian/Ubuntu) or /etc/clamd.d/scan.conf and /etc/freshclam.conf (RHEL family).

Recommended clamd.conf basics

# Common clamd.conf options (example snippets)
LogFile /var/log/clamav/clamd.log
LogTime yes
LogRotate yes
TCPSocket 3310
TCPAddr 127.0.0.1

# Performance and safety
MaxFileSize 200M
MaxScanSize 500M
MaxRecursion 16
MaxDirectoryRecursion 20
FollowDirectorySymlinks no
FollowFileSymlinks no

# Exclusions (adjust to your environment)
ExcludePath ^/proc/
ExcludePath ^/sys/
ExcludePath ^/dev/
ExcludePath ^/var/log/
ExcludePath ^/var/cache/

# Improve PHP web app detection
ScanHTML yes
ScanArchive yes
HeuristicScanPrecedence yes

Recommended freshclam.conf basics

# freshclam.conf snippets
DatabaseMirror database.clamav.net
DatabaseOwner clamav
Checks 12
DNSDatabaseInfo current.cvd.clamav.net
LogFile /var/log/clamav/freshclam.log
LogTime yes

After any config changes, reload services.

sudo systemctl restart clamav-daemon 2>/dev/null || sudo systemctl restart clamd@scan
sudo systemctl restart clamav-freshclam

Run Your First Full Scan (Safely)

Start with web roots or user upload directories. Avoid scanning /proc, /sys, and /dev. Use “–move” or “–remove” cautiously; begin with “–infected” to review findings before taking action.

# Dry run: list infected files only
sudo clamscan -ri --infected /var/www

# Move infected files to quarantine for review
sudo mkdir -p /quarantine
sudo clamscan -ri --move=/quarantine /var/www

# Daemon-backed equivalent (faster)
sudo clamdscan --fdpass --move=/quarantine /var/www

Schedule Regular Scans (cron or systemd)

Automate nightly or weekly scans and log results. Keep reports for audits and incident response.

# Example cron job: daily 2:30 AM scan of web root
sudo crontab -e

# Add:
30 2 * * * /usr/bin/clamdscan --fdpass -ri /var/www > /var/log/clamav/nightly-www.log 2>&1

If clamd is not enabled, swap clamdscan for clamscan (slower). For large estates, use systemd timers or a central scheduler.

Enable Real-Time (On-Access) Scanning with clamonacc

ClamAV’s clamonacc uses Linux fanotify to watch file operations and scan on access. This is powerful but can add overhead; restrict to high-risk paths (uploads) and exclude caches.

# Ensure clamd is running, then:
sudo clamonacc --fdpass --move=/quarantine --log=/var/log/clamav/onacc.log \
--include=/var/www/html/wp-content/uploads \
--exclude-dir=/var/cache --exclude-dir=/var/log

For persistence, create a systemd unit or use screen/tmux. Always test with synthetic samples (e.g., EICAR) before relying on production.

Tuning for Performance and Accuracy

• Targeted scanning: Focus on upload, backup import, and mail directories rather than the entire filesystem.
• Right-size limits: Increase MaxScanSize and MaxFileSize only if you handle large archives; avoid scanning ISO/VM images.
• Use clamd: Preloaded signatures reduce CPU thrash and cut scan time considerably.
• Exclude noisy paths: /proc, /sys, /dev, caches, session stores, and large package caches to prevent false positives and wasted cycles.
• Parallelize wisely: clamdscan with –multiscan can use multiple threads; validate impact on IO and CPU.

Integrations: Web and Mail Workloads

Web servers: Scan user uploads before saving to disk or asynchronously right after upload. Many CMSs support hooks or plugins; for Nginx/Apache, use tmp directories and a post-upload scan step.

Mail servers: Integrate clamd with Postfix/Amavis or Exim via Milter or content filter. Quarantine suspicious attachments and alert admins. Validate throughput in staging before rolling to production.

Logging, Alerts, and Reporting

Centralize ClamAV logs to your SIEM or log stack and enable email alerts on detections. A simple mailx script tied to cron output is often enough for small teams.

# Example: email if infected files are found
if sudo clamscan -ri /var/www | grep -q "Infected files: [1-9]"; then
  mail -s "ClamAV Alert on $(hostname)" admin@example.com < /var/log/clamav/www-scan.log
fi

Security Notes: Permissions, SELinux, AppArmor

• Run clamd as the clamav user (default). Use –fdpass with clamdscan to request file-descriptor passing for protected paths.
• SELinux/AppArmor: Ensure policies allow clamd read access to target directories. Adjust contexts or profiles rather than disabling the controls.
• Quarantine: Store quarantined files outside web roots, with restrictive permissions (e.g., 700) and no execute bits.

Troubleshooting Common Issues

• FreshClam database lock: Stop services, remove the stale lock, update, restart services.

sudo systemctl stop clamav-freshclam
sudo rm -f /var/lib/clamav/freshclam.dat.lock
sudo freshclam
sudo systemctl start clamav-freshclam

• “ERROR: Can’t connect to clamd”: Verify clamd is running and listening on 127.0.0.1:3310; check TCPSocket/TCPAddr and firewall.
• High CPU or IO: Limit recursion, exclude caches, and switch to clamd. Stagger scans during off-peak hours.
• False positives: Quarantine rather than delete. Submit samples to the ClamAV project for review.

Uninstall or Disable ClamAV (If Needed)

If you must remove ClamAV, stop services and uninstall packages. Keep quarantine and logs for audit.

# Debian/Ubuntu
sudo systemctl disable --now clamav-daemon clamav-freshclam
sudo apt remove -y clamav clamav-daemon clamav-freshclam

# RHEL family
sudo systemctl disable --now clamd@scan clamav-freshclam
sudo dnf remove -y clamav\*

When Managed Security Makes Sense

If you run mission-critical sites or don’t have time to tune signatures, alerts, and real-time scanning, consider managed hosting. At YouStable, our engineers harden Linux servers, configure ClamAV with smart exclusions, and monitor detections 24/7 so you can focus on growth, not malware hunts.

Best Practices Checklist

• Keep signatures current with freshclam and monitor update logs.
• Use clamd for production workloads; reserve clamscan for ad hoc checks.
• Scan upload and mail directories automatically; quarantine first, then review.
• Exclude system and cache directories to preserve performance.
• Enable alerts and retain scan logs for at least 30–90 days.
• Test with EICAR and validate your incident response process.

FAQ’s