Introduction

A home Linux file server often becomes the quiet workhorse of the household network. It stores documents, photos, installers, backups, archives, media, exported projects, and random files copied from Windows machines. When that same directory is shared to Windows 11 clients through Samba and published over HTTP by nginx, it becomes even more useful. It also becomes a place where malware, unwanted scripts, malicious documents, or infected downloads can sit unnoticed.

That is where ClamAV fits. ClamAV is not a replacement for good backups, careful permissions, patching, endpoint protection on Windows clients, or common sense. However, for a Linux Mint 21.3 home file server sharing /data/ through Samba and nginx, ClamAV provides a practical open-source antivirus layer. The official ClamAV documentation describes it as an open-source toolkit for detecting viruses, Trojans, malware, and other threats, with tools such as freshclam, clamd, clamscan, and clamdscan (Cisco Talos, n.d.-a).

Linux Mint 21.3 uses an Ubuntu Jammy package base, which makes the installation process familiar for Ubuntu-style administration (Linux Mint, n.d.).

The Target Design

The design in this article assumes a simple home server layout:

Windows 11 clients -> Samba share -> /data/

nginx web server -> HTTP access -> /data/

ClamAV daemon -> scheduled malware scans of /data/

freshclam -> automatic signature updates

rsync -> scheduled backup from /data/ to /data-backup/

systemd timers -> automation for scans and backups

The goal is to protect the shared file repository without making the server difficult to maintain. Files can arrive through Samba, be served later by nginx, and be scanned regularly by ClamAV. A separate scheduled rsync job keeps a local backup copy in /data-backup/.

Install ClamAV

Install the ClamAV packages:

sudo apt update

sudo apt install clamav clamav-daemon

The clamav package provides the basic scanner tools. The clamav-daemon package provides clamd, the scanning daemon. ClamAV documentation explains that clamdscan sends scan requests to clamd, while daemon behavior is controlled largely through clamd.conf (Cisco Talos, n.d.-b).

Enable and start the services:

sudo systemctl enable --now clamav-freshclam

sudo systemctl enable --now clamav-daemon

Check status:

systemctl status clamav-freshclam

systemctl status clamav-daemon

The clamav-freshclam service updates virus signature databases. The clamav-daemon service runs the scanner daemon.

Confirm Signature Updates

A healthy freshclam log should show database updates such as:

daily.cvd updated

main.cvd updated

bytecode.cvd updated

Database test passed

Check the updater logs:

sudo journalctl -u clamav-freshclam -n 100

sudo tail -n 100 /var/log/clamav/freshclam.log

A warning such as the following usually means the updater could not notify the scanning daemon:

WARNING: Clamd was NOT notified: Cannot connect to clamd through /var/run/clamav/clamd.ctl

That normally means clamd is not installed, is not running, or its socket was not available when freshclam tried to notify it. Restart both services:

sudo systemctl restart clamav-daemon

sudo systemctl restart clamav-freshclam

Then verify:

systemctl status clamav-daemon

systemctl status clamav-freshclam

Check ClamAV Logging

ClamAV logs are usually found under:

/var/log/clamav/

Useful log commands:

ls -lh /var/log/clamav/

sudo tail -f /var/log/clamav/clamav.log

sudo tail -f /var/log/clamav/freshclam.log

sudo journalctl -u clamav-daemon -f

sudo journalctl -u clamav-freshclam -f

To confirm the configured log file:

grep -E '^(LogFile|LogSyslog|LogFacility|LogFileMaxSize)' /etc/clamav/clamd.conf

The clamd.conf file controls daemon behavior, including logging, socket settings, scan limits, recursion limits, and thread configuration (Canonical, n.d.-a).

Make systemctl Easier to Use

On many systems, systemctl status opens in a pager. To make systemd tools behave as though --no-pager was used, set SYSTEMD_PAGER=cat:

echo 'export SYSTEMD_PAGER=cat' >> ~/.bashrc

source ~/.bashrc

For root:

echo 'export SYSTEMD_PAGER=cat' >> /root/.bashrc

source /root/.bashrc

Test clamdscan

Start small before scanning the full share:

sudo clamdscan -v --fdpass /etc/hosts

Then test the shared directory:

sudo clamdscan -v --fdpass --multiscan /data/

Useful clamdscan options include the following:

Option	Use
-v, --verbose	Shows more output during a scan.
--fdpass	Passes open file descriptors to clamd. This is useful when clamd runs as a different user.
--multiscan	Uses multiple daemon worker threads for directory scans.
--log=FILE	Writes scan output to a specified log file.
--move=DIRECTORY	Moves infected files to a quarantine directory.
--copy=DIRECTORY	Copies infected files to a quarantine directory while leaving the original in place.
--remove	Deletes infected files. Use cautiously on shared storage.
--reload	Asks clamd to reload signatures.
--ping	Checks whether clamd responds.

The --fdpass option is especially useful on a local Linux server because clamdscan can open files and pass the file descriptors to the daemon. ClamAV documentation notes that --multiscan lets directory scans use multiple daemon worker threads, and when combined with --fdpass, clamdscan walks the directory tree and submits individual file scans to the daemon (Cisco Talos, n.d.-b).

A practical manual scan command is:

sudo clamdscan -v --fdpass --multiscan --log=/var/log/clamav/manual-data-scan.log /data/

Prepare Permissions for Samba, nginx, ClamAV, and Backups

A file server serving the same directory through Samba and nginx has multiple access paths. Each service needs only the access required for its role.

Component	Access requirement
Samba users or groups	Write and read files through the Windows file share.
nginx worker process	Read files when serving static content over HTTP.
ClamAV scanner	Read files during scheduled malware scans.
Backup process	Read the source directory and write to the backup destination.

A practical pattern is to use a shared Linux group for write access and ACLs for service read access.

Create a file-sharing group:

sudo groupadd fileshare

Set group ownership:

sudo chgrp -R fileshare /data/

sudo chmod -R 2775 /data/

The 2 in 2775 sets the setgid bit on directories, helping new files inherit the directory group.

Grant nginx read and directory traversal access:

sudo setfacl -R -m u:www-data:rx /data/

sudo setfacl -R -d -m u:www-data:rx /data/

Grant ClamAV read and directory traversal access:

sudo setfacl -R -m u:clamav:rx /data/

sudo setfacl -R -d -m u:clamav:rx /data/

Verify ACLs:

getfacl /data/

When scans are launched with sudo clamdscan --fdpass, the root-launched client can open files and pass them to clamd. Even so, explicit ACLs for the clamav user make future troubleshooting easier.

Example Samba Share

A simple Samba share for /data/ might look like this:

sudo nano /etc/samba/smb.conf

Example share definition:

[data]

path = /data

browseable = yes

read only = no

guest ok = no

valid users = @fileshare

force group = fileshare

create mask = 0664

directory mask = 2775

Restart Samba:

sudo systemctl restart smbd nmbd

Windows 11 clients can connect using:

\\server-name\data

\\server-ip-address\data

Samba also provides a vfs_virusfilter module for on-access antivirus scanning on Samba file services, but scheduled scans are simpler and easier to troubleshoot for a home server. The Samba documentation describes vfs_virusfilter as a stackable VFS module for scanning and filtering virus files on Samba file services (Samba Team, n.d.).

Example nginx Static File Share

nginx can publish /data/ over HTTP as static content. NGINX documentation explains that the root directive defines the filesystem path used to serve requested files (NGINX, n.d.).

Create a site file:

sudo nano /etc/nginx/sites-available/data-share

Example configuration:

server {

listen 80;

server_name server-name;

root /data;

location / {

autoindex on;

try_files $uri $uri/ =404;

}

Enable the site:

sudo ln -s /etc/nginx/sites-available/data-share /etc/nginx/sites-enabled/data-share

sudo nginx -t

sudo systemctl reload nginx

For a home LAN-only service, restrict access by subnet:

server {

listen 80;

server_name server-name;

root /data;

location / {

allow 192.168.1.0/24;

deny all;

autoindex on;

try_files $uri $uri/ =404;

}

Adjust the subnet to match the local network.

Schedule ClamAV Scans with systemd

A systemd timer is a clean way to schedule scans. Timers are unit files ending in .timer and can activate matching .service units on a calendar schedule. The systemd.timer documentation describes timer units and the use of calendar-based scheduling through timer configuration (freedesktop.org, n.d.).

Create the scan script:

sudo nano /usr/local/sbin/clamav-scan-data.sh

Paste:

#!/bin/bash

LOGFILE="/var/log/clamav/scheduled-data-scan.log"

LOCKFILE="/run/lock/clamav-scan-data.lock"

SCAN_TARGET="/data/"

{

echo "============================================================"

echo "ClamAV scheduled scan started: $(date)"

echo "Target: ${SCAN_TARGET}"

echo "============================================================"

} >> "$LOGFILE"

/usr/bin/flock -n "$LOCKFILE" /usr/bin/nice -n 10 /usr/bin/ionice -c2 -n7 /usr/bin/clamdscan -v --fdpass --multiscan --log="$LOGFILE" "$SCAN_TARGET"

EXIT_CODE=$?

{

echo "============================================================"

echo "ClamAV scheduled scan finished: $(date)"

echo "Exit code: ${EXIT_CODE}"

echo "Exit code meaning: 0=no virus found, 1=virus found, 2=error"

echo "============================================================"

echo

} >> "$LOGFILE"

exit "$EXIT_CODE"

Make it executable:

sudo chmod 750 /usr/local/sbin/clamav-scan-data.sh

Test it:

sudo /usr/local/sbin/clamav-scan-data.sh

sudo tail -n 50 /var/log/clamav/scheduled-data-scan.log

Create the service:

sudo nano /etc/systemd/system/clamav-data-scan.service

Paste:

[Unit]

Description=Scheduled ClamAV scan of /data

Wants=clamav-daemon.service

After=clamav-daemon.service

[Service]

Type=oneshot

ExecStart=/usr/local/sbin/clamav-scan-data.sh

Create the timer:

sudo nano /etc/systemd/system/clamav-data-scan.timer

Paste:

[Unit]

Description=Run scheduled ClamAV scan of /data

[Timer]

OnCalendar=*-*-* 02:00:00

Persistent=true

Unit=clamav-data-scan.service

[Install]

WantedBy=timers.target

Enable the timer:

sudo systemctl daemon-reload

sudo systemctl enable --now clamav-data-scan.timer

Check it:

systemctl list-timers --all | grep clamav

systemctl status clamav-data-scan.timer

systemctl status clamav-data-scan.service

Watch the scan log:

sudo tail -f /var/log/clamav/scheduled-data-scan.log

Persistent=true is useful on a home server because the timer can catch up after a missed run if the machine was powered off during the scheduled time (freedesktop.org, n.d.).

Add a Scheduled rsync Backup from /data/ to /data-backup/

Antivirus is not a backup strategy. A clean ClamAV scan only means malware was not detected by the available signatures and scan engine. A backup helps protect against accidental deletion, hardware failure, user mistakes, ransomware damage, failed upgrades, and administrative errors.

This example uses rsync to mirror the contents of /data/ into /data-backup/.

Create the destination directory:

sudo mkdir -p /data-backup

Run a first manual test:

sudo rsync -aHAX --delete --numeric-ids /data/ /data-backup/

The trailing slash on /data/ matters. It means copy the contents of /data/ into /data-backup/, rather than copying the /data directory itself as a subdirectory. The rsync manual documents archive mode, deletion options, and local-copy behavior (rsync project, n.d.).

The options used here are:

-a Archive mode

-H Preserve hard links

-A Preserve ACLs

-X Preserve extended attributes

--delete Delete destination files that no longer exist in the source

--numeric-ids Preserve numeric user and group IDs

Use --delete carefully. It keeps the destination as a mirror of the source. That is useful for a clean local mirror, but it also means deletions in /data/ will eventually be reflected in /data-backup/.

Create the rsync Backup Script

Create the script:

sudo nano /usr/local/sbin/rsync-backup-data.sh

Paste:

#!/bin/bash

SOURCE="/data/"

DESTINATION="/data-backup/"

LOGFILE="/var/log/rsync-data-backup.log"

LOCKFILE="/run/lock/rsync-data-backup.lock"

{

echo "============================================================"

echo "rsync backup started: $(date)"

echo "Source: ${SOURCE}"

echo "Destination: ${DESTINATION}"

echo "============================================================"

} >> "$LOGFILE"

/usr/bin/flock -n "$LOCKFILE" /usr/bin/nice -n 10 /usr/bin/ionice -c2 -n7 /usr/bin/rsync -aHAX --delete --numeric-ids --info=stats2 "$SOURCE" "$DESTINATION" >> "$LOGFILE" 2>&1

EXIT_CODE=$?

{

echo "============================================================"

echo "rsync backup finished: $(date)"

echo "Exit code: ${EXIT_CODE}"

echo "============================================================"

echo

} >> "$LOGFILE"

exit "$EXIT_CODE"

Make it executable:

sudo chmod 750 /usr/local/sbin/rsync-backup-data.sh

Test it manually:

sudo /usr/local/sbin/rsync-backup-data.sh

sudo tail -n 50 /var/log/rsync-data-backup.log

Optional Safety Check for a Mounted Backup Disk

If /data-backup/ is expected to be a separate mounted filesystem, add a mount check to the script before the rsync command:

if ! /usr/bin/mountpoint -q /data-backup; then

echo "ERROR: /data-backup is not a mount point. Backup aborted: $(date)" >> "$LOGFILE"

exit 2

This prevents accidentally filling the root filesystem if an external or secondary disk is not mounted.

Schedule the rsync Backup with systemd

Create the service:

sudo nano /etc/systemd/system/rsync-data-backup.service

Paste:

[Unit]

Description=Scheduled rsync backup of /data to /data-backup

After=local-fs.target

[Service]

Type=oneshot

ExecStart=/usr/local/sbin/rsync-backup-data.sh

Create the timer:

sudo nano /etc/systemd/system/rsync-data-backup.timer

Paste:

[Unit]

Description=Run scheduled rsync backup of /data to /data-backup

[Timer]

OnCalendar=*-*-* 01:00:00

Persistent=true

Unit=rsync-data-backup.service

[Install]

WantedBy=timers.target

This schedules the backup for 1:00 AM. The ClamAV scan example runs at 2:00 AM, so the backup finishes first and the scan runs afterward.

Enable the timer:

sudo systemctl daemon-reload

sudo systemctl enable --now rsync-data-backup.timer

Check both scheduled jobs:

systemctl list-timers --all | egrep 'rsync|clamav'

Check the backup service:

systemctl status rsync-data-backup.timer

systemctl status rsync-data-backup.service

View backup logs:

sudo tail -f /var/log/rsync-data-backup.log

Backup First or Scan First?

A reasonable nightly schedule looks like this:

1:00 AM rsync /data/ to /data-backup/

2:00 AM ClamAV scan of /data/

This order gives the server a fresh backup before the antivirus scan runs. Another valid approach is to scan first and back up afterward, so detected files are not copied into the backup. There is no single perfect answer. For a home server, the most important point is that both jobs run consistently and produce logs.

A more cautious design is:

1:00 AM ClamAV scan of /data/

2:00 AM rsync /data/ to /data-backup/

That approach reduces the chance of copying suspicious files to the backup. However, if the scan takes a long time, the backup may overlap unless locks and scheduling are planned carefully.

Quarantine Instead of Delete

At first, avoid automatic deletion. A quarantine workflow is safer.

Create a quarantine directory:

sudo mkdir -p /var/quarantine/clamav

sudo chown clamav:clamav /var/quarantine/clamav

sudo chmod 700 /var/quarantine/clamav

To move detected files into quarantine, modify the scan command in the ClamAV script:

/usr/bin/clamdscan -v --fdpass --multiscan --move=/var/quarantine/clamav --log="$LOGFILE" "$SCAN_TARGET"

Avoid --remove until the behavior is well understood. The clamdscan documentation includes removal and quarantine-style options, but automatic deletion on a shared file server can create unnecessary operational risk (Canonical, n.d.-b).

Large Directories Require Patience

A large file share may appear to scan slowly. That is normal. File count matters as much as total size.

Estimate the size:

sudo du -sh /data/

sudo find /data/ -type f | wc -l

Watch ClamAV activity:

ps -eo pid,ppid,user,stat,pcpu,pmem,etime,cmd | egrep 'clamd|clamdscan'

sudo tail -f /var/log/clamav/scheduled-data-scan.log

Watch rsync backup activity:

ps -eo pid,ppid,user,stat,pcpu,pmem,etime,cmd | egrep 'rsync|rsync-backup'

sudo tail -f /var/log/rsync-data-backup.log

For disk I/O:

sudo apt install iotop

sudo iotop -oPa

Optional clamd Tuning

Check key daemon settings:

For a modest home server:

MaxThreads 4

MaxQueue 100

For a larger server with more CPU and RAM:

MaxThreads 8

MaxQueue 200

Restart the daemon after changes:

sudo systemctl restart clamav-daemon

MaxThreads and related scan behavior are part of clamd.conf, which controls daemon-side scanning rather than the clamdscan command alone (Canonical, n.d.-a).

Should On-Access Scanning Be Enabled?

ClamAV supports on-access scanning on Linux through ClamOnAcc. ClamAV documentation describes this as real-time protection that can scan files when they are accessed and can optionally block access while scanning occurs (Cisco Talos, n.d.-c).

For a home file server, scheduled scanning is usually the better first step. It is easier to understand, easier to log, easier to troubleshoot, and less likely to interfere with Samba or nginx performance. On-access scanning can be added later after permissions, scan speed, and logging are understood.

Administration Cheat Sheet

Check ClamAV services:

systemctl status clamav-daemon

systemctl status clamav-freshclam

Update signatures manually:

sudo freshclam

Reload signatures into the daemon:

sudo clamdscan --reload

Run a manual scan:

sudo clamdscan -v --fdpass --multiscan --log=/var/log/clamav/manual-data-scan.log /data/

Check ClamAV timer:

systemctl list-timers --all | grep clamav

systemctl status clamav-data-scan.timer

systemctl status clamav-data-scan.service

Run a manual rsync backup:

sudo /usr/local/sbin/rsync-backup-data.sh

Check rsync timer:

systemctl list-timers --all | grep rsync

systemctl status rsync-data-backup.timer

systemctl status rsync-data-backup.service

View logs:

sudo tail -f /var/log/clamav/scheduled-data-scan.log

sudo tail -f /var/log/rsync-data-backup.log

sudo journalctl -u clamav-daemon -f

Final Recommendation

For a Linux Mint 21.3 home file server that shares /data/ through Samba to Windows 11 clients and through nginx over HTTP, the most maintainable design is:

· Install ClamAV and clamav-daemon.

· Run freshclam automatically.

· Run clamd automatically.

· Use clamdscan with --fdpass and --multiscan.

· Scan /data/ on a systemd timer.

· Back up /data/ to /data-backup/ with rsync on a systemd timer.

· Log both scans and backups.

· Quarantine suspicious files before considering deletion.

· Keep Samba, nginx, ClamAV, and backup permissions explicit.

This gives the server a practical security and recovery baseline. ClamAV helps detect known malware in the shared repository. rsync provides a local backup mirror. Samba and nginx continue serving the same data through their normal paths. The result is a home file server that remains simple, visible, and maintainable.

References

Canonical. (n.d.-a). clamd.conf(5): Configuration file for Clam AntiVirus daemon. Ubuntu Manpages. https://manpages.ubuntu.com/manpages/jammy/man5/clamd.conf.5.html

Canonical. (n.d.-b). clamdscan(1): Scan files and directories for viruses using Clam AntiVirus daemon. Ubuntu Manpages. https://manpages.ubuntu.com/manpages/jammy/man1/clamdscan.1.html

Cisco Talos. (n.d.-a). ClamAV documentation: Introduction. ClamAV Documentation. https://docs.clamav.net/

Cisco Talos. (n.d.-b). ClamAV documentation: Scanning. ClamAV Documentation. https://docs.clamav.net/manual/Usage/Scanning.html

Cisco Talos. (n.d.-c). ClamAV documentation: On-access scanning. ClamAV Documentation. https://docs.clamav.net/manual/OnAccess.html

freedesktop.org. (n.d.). systemd.timer: Timer unit configuration. https://www.freedesktop.org/software/systemd/man/systemd.timer.html

Linux Mint. (n.d.). New features in Linux Mint 21.3 Virginia. https://www.linuxmint.com/rel_virginia_whatsnew.php

NGINX. (n.d.). Serving static content. NGINX Documentation. https://docs.nginx.com/nginx/admin-guide/web-server/serving-static-content/

rsync project. (n.d.). rsync(1): Linux man page. https://download.samba.org/pub/rsync/rsync.1

Samba Team. (n.d.). vfs_virusfilter: On access virus scanner. Samba Documentation. https://www.samba.org/samba/docs/current/man-html/vfs_virusfilter.8.h

Pete's Place

What's here:

Configuring a Home File Server on Linux Mint

Introduction

The Target Design

Install ClamAV

Confirm Signature Updates

Check ClamAV Logging

Make systemctl Easier to Use

Test clamdscan

Prepare Permissions for Samba, nginx, ClamAV, and Backups

Example Samba Share

Example nginx Static File Share

Schedule ClamAV Scans with systemd

Add a Scheduled rsync Backup from /data/ to /data-backup/

Create the rsync Backup Script

Optional Safety Check for a Mounted Backup Disk

Schedule the rsync Backup with systemd

Backup First or Scan First?

Quarantine Instead of Delete

Large Directories Require Patience

Optional clamd Tuning

Should On-Access Scanning Be Enabled?

Administration Cheat Sheet

Final Recommendation

References