Why Nextcloud antivirus scanning matters for shared files
Antivirus scanning in Nextcloud checks files as they are uploaded and, where configured, files already stored on the server, so that malware does not sit in a shared library waiting for the next person to open it. The Antivirus for files app connects Nextcloud to either a ClamAV daemon or an ICAP scanner. Teams need this when people upload files from outside the organization, such as clients, vendors, applicants or members of the public, or when internal users share files widely across groups and external links. If files only move between a small set of trusted internal users, the risk is lower, but many organizations still want a documented scanning control because file stores tend to grow beyond their original purpose. Scanning is one control among several, and it should not be presented to users or auditors as the whole answer. Identity controls decide who can upload and who can sign in. Sharing settings decide who can receive a file and through which links. Retention rules decide how long infected or sensitive content remains. Scanning only reduces the risk from known malware signatures or detectable content. Administrators should plan these controls together, so that a file flagged by the scanner is also limited in who can reach it and how long it is kept.
Before choosing a design, confirm two things in your own environment: scanner capacity and file-size limits. A scanner must read each file, so large uploads, bulk synchronization and many simultaneous users can create queues or timeouts. Ask your team to measure typical file sizes, peak upload hours and how the scanner host is sized, and to confirm the maximum size the scanner will accept and what Nextcloud does with files above that limit. These limits affect user experience and should be written down before rollout, because a file that cannot be scanned must still have a defined outcome. The deployment method also changes the planning work. Nextcloud All-in-One bundles ClamAV with the rest of its stack, so the scanner comes with the installation and the team's work shifts to sizing, updates and monitoring. Other installations must plan the scanner themselves, including where it runs, how it is kept current with signature updates, how Nextcloud connects to it over the network, and who owns it after go-live. An ICAP scanner, which is often already provided by an enterprise security platform, adds its own ownership and network questions. Settle these decisions early, because they determine the rest of the build.
Choosing between ClamAV and an ICAP scanner
This table compares the two ways to scan Nextcloud uploads: the ClamAV route that runs alongside Nextcloud, and an ICAP scanner your organization already operates. Read each row as a decision question, and treat every feature or version statement as something to confirm with the scanner vendor or the Nextcloud app documentation before you commit. In most cases the deciding factor is who already operates a scanner and how traffic already passes through your gateway.
| Decision factor | ClamAV route | Existing ICAP scanner |
|---|---|---|
| Who operates the scanner | Usually the Nextcloud team or platform team, as part of the Nextcloud host or stack | Your security or network team, which already maintains the scanner and its policies |
| Where it runs | Typically on or next to the Nextcloud host or in the same deployment, such as the ClamAV container in Nextcloud All-in-One | On a separate scanning tier that Nextcloud reaches over the network through an ICAP connection |
| Fit with gateway or proxy controls | Scanning is applied by the Nextcloud app, so it may not match gateway policy for other web traffic | Can reuse controls already applied at the reverse proxy or gateway, so one policy covers several applications |
| Signature and engine updates | Updated through the scanner deployment you run, so the Nextcloud team must schedule and test them | Updated by the team that owns the scanner, under its existing change process |
| Monitoring and alerting | Confirm which scanner health and error signals the Nextcloud app exposes and where to read them | Usually fits the existing security monitoring and incident workflow, but confirm the logs Nextcloud sends |
| Behavior on scanner outage | Confirm with the app documentation how uploads are handled when the scanner is unavailable | Confirm with your gateway and the Nextcloud app how a failed ICAP call is treated |
| When it fits best | Small or single-site deployments with no scanner in place and a team ready to run it | Organizations with a central scanning service, shared policy and an established operations team |
| What to confirm first | Supported ClamAV versions, app version compatibility and how the app reports infected files | ICAP protocol support, the request and response mode used by the app, and vendor support for Nextcloud traffic |
How background scans and upload checks work together
Nextcloud antivirus scanning covers two different moments, and an administrator needs to decide how each one is handled before users rely on the file store. The first is the upload, when a file arrives from a browser, sync client or share and can be checked as it is saved. The second is the background scan, which examines files already stored on the server on a schedule or on a triggered basis. The Antivirus for files app and its scanner backend, whether ClamAV or an ICAP service, make both possible, but the configuration decisions remain with your team. Confirm which checks your installed version of the app supports and where each one is switched on in the admin settings.
Checking only at upload leaves a gap. A file that passed inspection on the day it was uploaded can later be replaced by a malicious version through a sync client, a share edit or a compromised account, and the replacement may never pass through the upload path again. The reverse gap also exists. Scanner signature databases are updated over time, so a file that was clean when it was stored may match a newer signature. A background scan is the mechanism that catches both cases. It does not replace upload checks, because it runs after the file is already reachable by users and sync clients. Treat it as a second control with different timing, and plan in advance how a late detection will be handled.
Four decisions shape the setup. First, decide which scan triggers apply. Uploads through the web interface, sync clients and WebDAV writes are separate entry points, so map how your users actually add and change files and confirm that each one is covered. Second, decide how often background scans run and over which scope. A full rescan of a large instance takes longer and adds load to both the scanner and the storage, so the schedule should match your data volume and your tolerance for delayed detection. Third, decide what happens to an infected file: whether it is blocked, quarantined or only flagged, and whether it stays downloadable. Fourth, decide who receives alerts, such as a security mailbox, the service desk or the file owner. Record these answers before rollout, because they determine who acts when the first detection arrives.
Verify the exact settings in the version you run. Trigger options, schedule controls and alert destinations can differ between app releases and between ClamAV and ICAP configurations, so the admin screens and the app documentation for your installed Nextcloud version are the source of truth. After configuration, run a harmless test file, such as the standard EICAR test string that scanners are designed to detect, to confirm that upload checks fire, that background detection finds a file placed on the server afterward, and that alerts reach the people you named. Repeat the test after any scanner update or Nextcloud upgrade, since either change can alter behavior that worked before.
Setting up antivirus scanning in Nextcloud step by step
This sequence takes a Nextcloud server from a version check to a tested scanning path, with ClamAV or an ICAP scanner running in a network segment the server can reach. It ends with a runbook that tells administrators what to do when an infected file is found. Each step closes with a check you can repeat after changes.
Confirm the Nextcloud version and requirements
Start by recording the Nextcloud version you run and reading the system requirements page for that release. Confirm the supported PHP version, the database engine and version, and whether your web server uses Apache or nginx with php-fpm, since the scanner setup depends on a supported base. Check that your current major version can be upgraded in the order your plan requires, because Nextcloud requires upgrading one major version at a time. Record the values in your change ticket. Done when the written list matches the requirements page for your release and the administration overview shows no outstanding warnings about the server environment.
Choose ClamAV or an ICAP scanner
Decide which engine will inspect files. ClamAV is an open-source engine that the Antivirus for files app can call, and Nextcloud All-in-One documents ClamAV as one of its bundled components. An ICAP scanner suits organizations that already run a content inspection service and want one policy across web and file traffic. Confirm with your security team how signatures are updated, who owns the update process, and whether the engine's licensing fits your use. Done when the engine choice, its owner and the reason for the choice are written down and approved.
Deploy the scanner in a reachable network segment
Install the scanner in a network segment that the Nextcloud server can reach on the scanner's service port, and keep it out of user-facing networks. For ClamAV, the scanner usually runs as a daemon on a host or container that Nextcloud connects to over the network. For ICAP, confirm the service address and whether the scanner accepts the request types your integration sends. Restrict inbound access so that only the Nextcloud server can connect, and confirm that signature updates run on schedule. Done when a connection test from the Nextcloud host succeeds and the scanner reports its signature database version.
Install and configure the Antivirus for files app
In the Nextcloud app store, install the Antivirus for files app and open its administration settings. Select the scan mode that matches your engine, then enter the host, port or service address. Set the timeout and maximum file size that your environment requires. Confirm the exact option names in the app documentation for your Nextcloud version, because settings can change between releases. Save the configuration and use any connection test the app provides. Done when the connection test passes and the Nextcloud log shows no errors from the scanner connection.
Test uploads with a harmless test file
Use the standard antivirus test file, a harmless string that most engines flag as a test signature. Upload it through the web interface and through the desktop client as an ordinary user, then confirm that the upload is blocked or flagged according to the app's configured behavior. Open the scanner log and find the matching event with the file name and timestamp. Upload a clean file as well to confirm that normal files pass. Done when the test file is blocked or flagged, the clean file is accepted, and the scanner log shows both events.
Enable background scans for existing files
Scanning on upload does not cover files stored before the app was enabled, so configure background scanning for existing content. Confirm how your installation runs background jobs, and whether the server uses system cron, since scheduled scanning depends on that setting. Start with a limited scope, such as one test group folder, and watch the load on the scanner and the Nextcloud server. Place a test file in that folder and wait for the scheduled job. Done when the test file is picked up by the background job and the scanner log records the background event.
Define the infected-file runbook
Write the steps that operations and security teams follow when a file is flagged. Cover who receives the alert, how the file is quarantined or removed, whether the uploader and file owner are notified, how you find other shares that link to the file, and when to escalate to incident response. List the evidence to keep, such as the scanner log entry, file metadata and sharing records. Walk through the runbook as a tabletop exercise using the standard test file. Done when the security owner approves the runbook and the exercise confirms that each contact and step works.
Security and operational controls to set around scanning
A scanner only reduces risk if its signatures stay current, its path from Nextcloud is controlled, and someone owns what it finds. The controls below cover those operating decisions, along with the patch, backup and incident practices that keep scanning working after the first deployment.
Signature currency and update monitoring
ClamAV detects threats through signature databases that must be refreshed on a schedule. Confirm that freshclam or your equivalent updater runs on the scanner host, that the update source is reachable from that host, and that failed updates raise an alert. A scanner with stale signatures will still report clean results, so monitor the age of the database as well as whether the service is running.
Network path between Nextcloud and the scanner
Nextcloud sends file content to the scanner over the network, so the scanner should accept connections only from the Nextcloud application servers on the port it uses. Restrict the scanner's outbound access as well, allowing only the update sources it needs. Check that the path is encrypted where your policy requires it, and test the restriction from a host that is not part of Nextcloud to confirm it is closed.
Scanner log protection
Scanner logs record which files were checked, which were flagged and which failed, so they are evidence during an investigation. Send them to a central log store that the Nextcloud administrators cannot silently edit, set retention that matches your records policy, and restrict read access to the people who handle incidents. Confirm that log entries include file identifiers that can be matched to Nextcloud's own audit records.
Release authority for flagged files
Decide in advance who may release a quarantined or flagged file back to users, who must approve the release, and whether a second reviewer is needed for files that were flagged by a signature match rather than a suspicious result. Record the approver and the reason for each release. Without a defined owner, flagged files either stay blocked indefinitely or are released by whoever is available.
Incident recording and response steps
Define what counts as an infected-file incident, how it is recorded, and what happens next: who is notified, whether affected accounts or shares are reviewed, and whether the file was shared externally before it was flagged. Keep a simple record for each event with the time, file path, detection name, owner and outcome, so patterns across incidents become visible.
Patch cycle alignment with Nextcloud upgrades
Nextcloud releases a new major version every four months and supports each for one year, so the scanner integration must be retested whenever the server is upgraded. Keep the scanner and its connector on the same patch cycle as Nextcloud, and check the app's compatibility before each major upgrade. Upgrades also require a backup first, so include the scanner configuration in that backup.
Configuration backup and recovery
Back up the scanner configuration, the Antivirus for files settings, the scanning schedule and the update configuration, not only the Nextcloud data. After a rebuild, confirm that a known test file is detected and that background scans resume. Store the backup where a scanner host failure does not also remove it, and document who can restore it.
How large uploads and scan timing affect performance
Scanning large uploads adds time and load in three ways, and each one shapes how you size the scanner and set expectations for users. First, the scanner cannot start until the file is fully available to it. With ClamAV, the Antivirus for files app hands the file to the daemon, so the whole object must be written and readable before a verdict is possible. With an ICAP service, the file travels over the network to the scanner, so transfer time and scanner processing time both count. Second, scanner capacity is shared. Every user's uploads, and every background scan of existing files, compete for the same daemon threads, ICAP service slots and CPU. A single team uploading multi-gigabyte design files can delay scans for everyone else. Third, synchronous scanning sits in the upload path, so a slow verdict can make the client appear stalled.
Several design choices control this. Scanner sizing comes first: decide how many concurrent scans each scanner instance should handle, how much memory and temporary disk each scan needs, and how many instances you need for peak upload hours. File size limits are the next lever. Setting a maximum size for scanned uploads, and deciding what happens to files above it, keeps outliers from monopolizing capacity. Consider whether oversized files are blocked, accepted with a warning, or queued for a background scan. Timing is the third choice. Scanning on upload gives the strongest protection for shared links and sync clients, while background scanning of stored files reduces upload latency but leaves a window where a file is available before it has a verdict. Many administrators combine both, with a short synchronous check and a scheduled sweep afterward.
Timeouts and behavior on timeout need explicit values. Define how long Nextcloud waits for a verdict, what the user sees, and whether a timed-out file is rejected, quarantined or accepted and flagged for later review. Failing open makes the upload succeed but weakens protection, while failing closed protects data but can block legitimate work during a scanner outage. Record that decision in your security baseline and test it. The numbers for file sizes, concurrency, timeouts and scanner resources must be measured in your environment, not copied from defaults. Build a test set with representative file types and sizes, including the largest files your users actually send, and measure upload completion time, scanner queue depth and memory use at realistic concurrency.
Nextcloud's own upload limits and the reverse proxy in front of it also change the results. Chunked uploads, PHP upload and request size settings, and the web server's body size limit all determine when a file is complete and how it is staged on disk. A proxy with its own timeout may cut off a scan that Nextcloud is still waiting on, which then looks like a scanner fault. Confirm the limits in each layer, the temporary storage location and the timeout values together, and confirm them against the documentation for your Nextcloud version and proxy before you run performance tests.
Limits to confirm before you roll scanning out
Antivirus scanning in Nextcloud depends on the app version, the scanner's access to file content, and how the rest of your file tooling handles the same objects. Each item below is a point where a scanner that looks correct on paper can leave files unscanned or create operational surprises. Confirm every one in the app documentation and in a test environment that mirrors your production setup.
Supported Nextcloud and scanner versions
Check which Nextcloud server versions the Antivirus for files app supports, and which ClamAV or ICAP scanner versions that app release is tested against. Nextcloud ships a new major version every four months and supports each for one year, so a scanner setup validated on one release may need retesting after an upgrade. Record the exact combination you will run and treat it as the baseline for every future upgrade.
Encrypted files and end-to-end folders
Confirm how the scanner behaves with server-side encrypted files and with end-to-end encrypted folders. In an end-to-end encrypted folder the server holds only ciphertext, so the scanner may never see plaintext and can report nothing useful. Test an upload into each folder type, record what the scanner sees, and decide whether those folders need a client-side control or a documented exception.
Handling of unscannable files
Determine what happens to files the scanner cannot read, such as oversized files, password-protected archives, unsupported formats, or files that time out. Confirm whether the app blocks the upload, allows it with a flag, or silently passes it, and whether an administrator receives a notification. Write down the expected outcome for each case so that your security team and help desk handle them the same way.
Placement in a segregated network
Confirm whether the scanner can run in a separate network zone, such as a scanning segment with restricted egress, and which connections the Nextcloud server must open to it. Check the protocol and port the app uses to reach ClamAV or the ICAP service, and whether the scanner needs outbound access to fetch signature updates. Validate the path in your test environment before you open the firewall rules for production.
Interaction with full text search and retention
Verify how scanning interacts with full text search indexing and with retention and deletion rules. A file quarantined or removed by the scanner must also leave the search index, and a retention rule must not delete a file while a scan is pending. Test the sequence of upload, scan, index, and delete with a sample file so you know which component acts first and what a user sees at each step.
Questions teams ask before hiring help with antivirus scanning
What drives the cost of Nextcloud antivirus scanning work?
The main drivers are the number of scanners, how complex the environment is, how much the scanning has to connect to existing controls, and how far the testing goes. Number of scanners: a single ClamAV daemon behind one Nextcloud instance is a smaller job than several ClamAV or ICAP scanners behind a load balancer. Environment complexity: Nextcloud deployments with clustered application servers, separate object storage, or air-gapped networks need more design and more verification. Integration: linking scan results to your SIEM, ticketing, quarantine process or email alerts adds effort. Testing scope: test files, large-upload timing and failure-mode tests all take time. Ask any provider to price each of these items separately in the written quote so you can see which ones you do not need.
How long does antivirus scanning implementation take?
The duration depends on the scope you agree and on how long approvals and change windows take on your side, so no fixed timeline applies across deployments. Scope items that extend the schedule include scanner sizing, ICAP or ClamAV connectivity testing, background scan scheduling, handling infected-file workflows and performance testing on large uploads. Approvals matter as well: security sign-off on scanner placement, change advisory board slots for production changes and data-handling reviews can each add waiting time that no vendor controls. Ask for a written plan that lists each milestone, the approver for each one, and the change windows the plan assumes.
What does our team need to provide for the engagement?
Your team needs to provide environment access, representative test files, named runbook owners and agreed change windows. Environment access: administrator access to the Nextcloud server, the scanner hosts, and the network segments between them, through your normal access process. Test files: a set of clean and deliberately safe test samples, plus sizes that reflect your real upload patterns, so performance tests mean something. Runbook owners: people who will own the procedure for infected files, quarantine release and escalation after handover. Change windows: dates when Nextcloud and scanner configuration can be changed in production. Confirm these inputs in writing before work starts, because missing items are a common reason schedules slip.
Can one in-house administrator set up Nextcloud antivirus scanning alone?
A single experienced Nextcloud administrator can often install the Antivirus for files app and connect a single ClamAV instance, but the job becomes harder to do alone when several scanners, ICAP or network controls, background scans and performance testing are involved. The risk is less about the install itself and more about the parts that need a second pair of eyes: scanner placement, the handling procedure for infected files, and tests on large uploads. Also consider who covers the work during leave and who applies scanner updates. Before deciding, list the tasks, check which skills your team already has, and ask whether a partner would handle only the parts you cannot cover.
Which parts of antivirus scanning cost money every year?
One-time costs cover design, installation, integration and testing. Recurring costs cover the scanner software or subscription, the hosts that run it, and the staff time to keep signatures, the Nextcloud app and the scanner current. Nextcloud's own maintenance and release cycle also affects the work: each major version is supported for one year, and upgrades must go one major version at a time with a backup before each step. Antivirus configuration may need checking on each upgrade. Ask the provider to separate one-time and recurring items in the quote, and to state who pays for ClamAV or ICAP licensing, if any applies to your chosen scanner.
How do we confirm the scanner is working after go-live?
Confirm the scanner works by testing the full path from upload to decision, not only by checking that the service is running. Upload a harmless test file and confirm it is accepted, then upload a standard test signature that the scanner should flag, and confirm the file is blocked or quarantined according to your procedure. Check that background scans run on stored files on the schedule you set, and that alerts reach the people named in the runbook. Repeat large-file tests after any upgrade. Ask the provider to include these checks in the acceptance criteria and to document the results as evidence for your records.
What should a written quote for this work include?
A written quote should list the scope in named items, the deliverables for each, the assumptions about your environment, and the inputs you must provide. Ask for the number of Nextcloud instances and scanners in scope, the ClamAV or ICAP option chosen and why, the integrations included, and the testing items with their pass criteria. The quote should state the change windows assumed, the approvals the plan depends on, and what happens if an approval slips. Ask which items are one-time and which recurring, who holds licenses, what documentation you receive, and how post-go-live support is handled. A clear quote makes it easier to compare options, including doing part of the work in-house.
How DeployOpen scopes and delivers Nextcloud scanning
DeployOpen plans Nextcloud antivirus scanning as a fixed-scope engagement in infrastructure you control, starting from how uploads arrive and which scanner your team will run. The written scope sets out the Antivirus for files app or ICAP connection, background scan behavior, infected-file handling and the tests that prove each path works before go-live.
How we scope
- Map every upload path, including web, desktop and mobile sync, WebDAV and external sharing, to confirm which files reach the scanner.
- Decide between ClamAV run by your team and an ICAP scanner you already operate, and record the reasons in the written scope.
- Agree the file size limits, background scan schedule and quarantine rules that the scope will cover and test.
How we build
- Install and configure the Antivirus for files app or the ICAP connector on the Nextcloud version your scope names, then wire it to the scanner.
- Load signature updates on a schedule your operations team owns, and test that scanner outages fail in the way your policy requires.
- Run test uploads with clean, infected and oversized files through the web, sync client and background paths before sign-off.
How we hand over
- Document the scanner architecture, configuration values, quarantine and notification steps, and the test cases used to verify them.
- Provide a runbook for handling an infected file, including who is notified, how the file is isolated and how users are informed.
- Walk your administrators through the upgrade checks needed when Nextcloud or the scanner changes, including disabling third-party apps until compatibility is confirmed.
How we support
- Engagements are fixed-scope, and changes after sign-off are scoped and quoted separately in writing.
- Ongoing support, scanner updates and upgrade testing are available as a retainer if your team wants DeployOpen to keep the scanning path current.
- Ask any quote to state who maintains the scanner, who applies signature updates and who responds to a failed scan.
