Malware Scanning catches an infected file as it arrives, before anyone opens it and before your own workflows carry it anywhere else. Turn it on for a folder and Files.com scans every file uploaded into that folder.

While the scan runs, the file is visible at the path it was uploaded to but cannot be downloaded, previewed, moved, copied, or renamed. A clean file is released and stays there. An infected file never becomes available at all, because Files.com removes it from the folder and moves it to quarantine.

The setting applies to the folder you choose and every folder beneath it, and a subfolder cannot override or disable it.

Malware Scanning is available on the Enterprise plan. There is no scanner to deploy and no policy to write. Choosing the right folders is the only decision you make.

Which Folders to Protect

Protect the entry points. A file is scanned when it is uploaded, so the folder receiving that upload is the one that needs the setting. Once a file has been checked there, moving or copying it elsewhere on your site does not require another scan.

An infected file that gets in does not stay where it landed. A Share Link sends it to recipients outside your organization. An Automation or a Sync pushes it to a remote server or a partner's system. Copies and moves spread it across your own storage. One upload becomes many files in many places.

In practice that means the folder behind an Inbox, the folder an upload-enabled Share Link writes into, and any folder you share with customers, vendors, partners, or contractors. Some of those people have an account on your site. Others upload without signing in at all.

A file that moves or is copied into a protected folder is not scanned on arrival, because it was not uploaded there. Putting the setting on a folder that an Automation delivers into therefore protects nothing. Those files were uploaded somewhere else, and that somewhere else is the folder to protect.

A Sync works differently. Files that a Sync delivers into a protected folder are scanned.

Turning the setting on does nothing to files already in the folder either. It applies to new uploads from that point forward, and there is no way to scan a folder's existing contents.

Files larger than 100 GB pass through without a scan and without a charge. Three other routes into a folder never trigger a scan at all, including automatic remote server mounts and writes made directly to your external storage.

How Scanning Works

Files.com scans uploads using Amazon GuardDuty Malware Protection. Scanning happens in the same region your folder's storage is in, so file data never leaves its region.

When you upload a file into a protected folder, Files.com holds it for scanning rather than placing it in your storage. The file stays locked for as long as the scan runs, and an upload that would overwrite it is blocked as well. Deleting still works.

On a Remote Server Mount the file does not appear at all until the scan clears it, because Files.com holds the bytes rather than sending them on.

Any action that needs the contents of the file fails with an error stating that the resource is not available while being processed.

A scan ends in one of four ways. Only the last one is reported anywhere. For the other three, the state of the file is your only indication of what happened.

When no threats are found, Files.com releases the file and it stays at the path it was uploaded to.

When a threat is found, the file leaves the folder for quarantine. Files.com sends no notification, fires no webhook, and records no event.

When Files.com cannot open the file, it releases the file anyway. The file stays at that same path, and nothing shows that it went unscanned. Password-protected archives are the common case, because the scan cannot read what is inside them.

When the scan cannot be completed at all, the file stays visible at its path and stays locked. This covers a scan that failed, a file that could not be reached for scanning, and a scan that returned no result within six hours. Files.com records the failure on the Pending Work log.

Files.com reports nothing else about scanning. There is no scan status on a file, nothing in the file browser to show a scan is running, and no result to read back through the API, so a file waiting for a malware scan looks the same as a file waiting for any other processing.

Enabling and Removing the Setting

Malware Scanning is a Folder Setting. Scanning uses transformation credits.

Site Administrators can apply Malware Scanning to any folder, including your site root. Workspace Administrators can apply it within their Workspace, and Folder Admins can apply it to folders they administer.

None of them can switch it off below a folder that already has it, so protection can only be increased further down the tree, never reduced. A folder that inherits the setting shows which folder it comes from.

If a folder beneath the one you chose already has its own Malware Scanning setting, Files.com refuses to create the parent setting and names the conflicting subfolder paths. Delete those settings first, then apply the setting to the parent.

Deleting the setting stops scanning for new uploads. It does not affect files that were already scanned, and it does not release anything from quarantine.

Workspaces

A Malware Scanning setting at your site root does not cover named Workspaces. Each Workspace needs its own setting at the Workspace root.

Malware Scanning vs. File Extension Restrictions

Limit Uploaded Files To Certain File Extensions judges a file by its name. Malware Scanning inspects what is inside it. Blocking .exe uploads tells you nothing about whether the .pdf that arrived is safe, and scanning a folder does nothing to keep out a file type your workflow cannot process.

The sender's experience also differs. An extension rule rejects the upload as it happens, and the sender sees the error. Malware Scanning accepts the upload, holds the file, and automatically removes it when it finds a threat. The sender sees no error at any point.

Use both on a folder that accepts outside uploads. The extension rule keeps out file types you never want, and scanning checks the contents of the ones you do.