This guide walks through creating a Storage Protect connection that continuously scans a
Windows file share (SMB/CIFS) for viruses, malware and content threats, and applies your
configured actions (tag, delete, move, quarantine) the moment a file lands on the share.
It covers two scenarios:
- A network share you reach by UNC path, e.g.
\\foo\bar
- A share that is mounted as a local drive on the node, e.g.
Z:\ mapped to \\foo\bar
Recommendation up front: even when the share is mounted as a local drive, connect
Storage Protect directly to the share's UNC path (\\foo\bar), not to the drive letter.
Section 2 explains why.
Prerequisites
- A Cloudmersive Private Cloud node with the Storage Protection Service installed and
running (see StorageProtectionService-Windows-Install). The service logs to
C:\Cloudmersive\storageprotectionservice.log — you will use this log to verify the
connection below.
- The Storage Protect feature enabled on your Cloudmersive account.
- Network reachability from the node to the file server (SMB, TCP 445).
- Credentials for the share (domain, username, password), unless the node's service account
already has access.
Section 1 — Connecting to a network share (\\foo\bar)
1. Create the connection in the portal
-
In the management portal, go to Storage Protection and choose Add Storage
Connection.
-
Select the storage type Network Share SMB / CIFS.
-
Fill in the connection details:
| Field | What to enter |
|---|---|
| Connection Name | A friendly name, e.g. Finance Share |
| Network Share Path | The fully-qualified UNC path, e.g. \\foo\bar or \\foo\bar\subfolder. Subfolders below this path are monitored too. |
| Domain (Optional) | The account's domain, e.g. CONTOSO |
| Username / Password (Optional) | An account with read access to the share — plus delete/write permission if you use the Delete, Move or Quarantine actions. Connection data is stored encrypted. |
-
Choose the SMB Access Client:
- Windows Client (default — recommended) — accesses the share through the node's
Windows SMB stack. This is the right choice for most environments, and required for
environments that use Kerberos authentication.
- Cloudmersive Client — connects to the share directly with the credentials you entered
(SMB 2.x/3.x, NTLM), independent of Windows drive mappings and the service account. Use
this only when the Windows Client is not an option — for example when the node's service
account cannot be granted share access, or on non-domain-joined nodes. Requires Storage
Protect service version 2.0.0 or later.
-
Configure Polling if your file server does not reliably deliver SMB change
notifications — Azure Files shares are the common case and should use polling:
- Disabled — change notifications only (fine for most on-premises Windows file servers).
- Automatic — polls only while change notifications are unavailable.
- Always — change notifications plus a periodic sweep (recommended for Azure Files).
Files found by polling are de-duplicated against change notifications, so nothing is
scanned twice. The default interval is 300 seconds; Advanced polling settings let you
limit recursion depth, choose the sweep algorithm, and decide whether the first sweep
scans pre-existing files or only establishes a baseline.
-
Save the connection.
2. Configure scanning and outcome actions
Open the connection's Edit page to configure:
- Scan Type — Basic Scan, Advanced Scan (content threats such as executables, scripts,
macros, password-protected files), or Multi-Threat Scan (requires node version 1.3.0+).
- Clean File Action — e.g. add a result tag, copy, or move clean files.
- Infected File Action — Delete, Tag, Copy + Tag, Move, or the quarantine actions
(Quarantine In Place / Quarantine Move, node version 2.8.0+ — the infected file is
wrapped into an encrypted zip named filename.quarantined.zip; default password
infected).
- Optional logging and callback integrations — Azure Log Analytics, AWS CloudWatch Logs,
AWS Kinesis, webhook, Azure EventGrid, and email notifications.
After saving changes, use Push Configuration on the deployment page so the node picks up
the new settings.
3. Verify
On the node, watch the service log:
Get-Content C:\Cloudmersive\storageprotectionservice.log -Tail 20 -Wait
You should see the connection come online:
Connection to SMB share...
Connection to SMB share... Done.
Monitoring: \\foo\bar
Drop a test file (for example an EICAR test file) onto the share and confirm the scan and
your configured action:
File event: processing \\foo\bar\eicar.com
Performing Advanced Scan: \\foo\bar\eicar.com
Scan result: NOT CLEAN - \\foo\bar\eicar.com
Quarantined in place: \\foo\bar\eicar.com -> \\foo\bar\eicar.com.quarantined.zip
Section 2 — When the share is mounted as a local drive (Z:\)
It is common for a share to be mounted on the node as a drive letter, e.g.:
Z:\ → \\foo\bar
Recommended: connect to the underlying UNC path, not the drive letter
Do not enter Z:\ as the Network Share Path. Instead, find the UNC path behind the
mapping and create the connection against that path exactly as in Section 1.
To see what a drive letter is mapped to:
Get-SmbMapping
# or
net use
Why the UNC path is the right choice:
- Drive letters are per-user. A mapped drive belongs to the interactive user session that
created it. The Storage Protection Service runs as a Windows service under its own account,
which does not see your Z: mapping — so a connection pointed at Z:\ typically fails
to resolve even though the drive "works" when you are logged in.
- Mappings are not durable. Drive mappings can disappear at reboot, sign-out, or when
credentials expire. The UNC path plus the credentials stored on the connection work
regardless of who is logged in.
- Better change detection. Connecting to the share directly gives the service its own
SMB session for change notifications and polling, rather than depending on the state of a
mounted session.
Keep the recommended Windows Client here too. Only if the node's service account cannot
be granted access to the share, switch the SMB Access Client to the Cloudmersive Client —
it authenticates with the credentials stored on the connection and does not depend on the
service account at all.
Genuinely local folders
If the folder really is local storage on the node itself (for example D:\IncomingFiles,
not a mounted share), enter the local absolute path as the Network Share Path. Local paths
are fully supported; the SMB Access Client setting is ignored for them.