Skip to main content

NinjaOne Network Share Backup Plans — Backing Up NAS Shares

Audience: T2 / T3 Use when: Data lives on a NAS or SMB share that cannot run the NinjaOne agent (QNAP, Synology, UNAS, or any appliance), and that data needs to be backed up.

What This Plan Type Is

NinjaOne offers three backup plan types on a Windows endpoint: Image, File/Folder, and Network share. The Network share plan backs up SMB shares on devices that cannot run the agent themselves.

A Windows endpoint at the site acts as the mover — it reads the SMB share and ships the data. The NAS itself is never enrolled in NinjaOne.

Location: Device → Backup → Network share → Add a Network share plan

Critical: Cloud-Only Destination

The Backup destination field is locked to "Cloud." Network share plans have no local leg. Data goes directly to NinjaOne cloud — it does not land on the site NAS.

This is the opposite of the Image plan standard in NinjaOne Image Backup Plan Configuration Standard (page 1421), which mandates Hybrid.

Consequences:

  • You get offsite protection for free — this is the main advantage over a NAS-to-NAS sync
  • You get no fast local restore — recovery pulls from cloud, so RTO depends on download speed
  • It consumes cloud storage separately from any Image plan on the same device. Check the billing impact before deploying against large shares.

Comparison With HBS3 Sync

For a QNAP specifically, the alternative is a native HBS3 sync to a local NAS (QNAP → UNAS Nightly Sync via HBS3, page 4110).

Network share plan HBS3 sync to local NAS
Offsite copy Yes (cloud) No — both copies on site
Fast local restore No Yes
Versioning Revision limit in plan NAS snapshots only
Depends on a Windows PC Yes No
Config lives on NinjaOne The QNAP
Extra cost Cloud storage None (unless cloud destination added)
Visible in NinjaOne reporting Yes No

Running both is defensible — local fast-restore plus offsite. Running only HBS3 leaves no offsite copy. Whichever you choose, document it; do not leave a site with two half-configured mechanisms and no clarity on which is authoritative.

Prerequisites

  • A Windows endpoint at the site with the NinjaOne agent, on the same subnet as the NAS
  • A non-admin user on the NAS with read access to the in-scope shares (see Client Credential Administration Standard)
  • Credentials stored in IT Glue
  • Known data volume for the shares in scope
  • NAS on a static IP or DHCP reservation

Procedure

Step 1 — Create the NAS user

On the NAS, create a dedicated non-admin account with read access to the in-scope shares only. Never use an admin account.

On a QNAP: Control Panel → Privilege → Users → Create. Group everyone only, RW on in-scope shares, File Station application privilege only.

Step 2 — Open the plan dialog

Device → Backup → Network share → Add a Network share plan

Step 3 — General tab

Setting Value
Plan Name <Client> <NAS> Shares — Network Share Backup
Backup destination Cloud (locked, not editable)
Schedule Daily
Time Outside business hours, offset from any Image plan on the same device. If the Image plan runs 12:00 AM, use 1:00 AM.
Prevent device from sleeping Checked
Attempt to wake device if sleeping Checked
Run plan immediately if missed Checked
Limit revisions to 30
Trim revisions older than Unchecked
Remove locally deleted files older than Unchecked
Pre/post plan scripts Unchecked

The default schedule time is 5:00 PM — change it. That is inside business hours for most clients.

Leave "Remove locally deleted files older than" unchecked. Unchecked means files deleted from the share stay in the backup. This is the opposite of a mirror and is the safer default — an accidental deletion on the NAS remains recoverable.

The mover endpoint must stay powered and awake. If it sleeps, the job fails silently every night.

Step 4 — Target tab: credentials

+ Add credential → Add new local storage credential

Field Value
Name <NAS hostname> Share Access
Domain Leave blank for a workgroup NAS
Username The non-admin NAS user
Password From IT Glue

If Test fails with a known-good password, put . in the Domain field. This is the equivalent of the .\ prefix used when mapping from Windows, and it scopes auth to the device rather than a domain.

Step 5 — Target tab: add shares

For each in-scope share:

Field Value
Name Descriptive label, e.g. QNAP FILE SHARE
Path \\<NAS IP>\<Share Name>
Existing credentials Select the credential from Step 4

Test must pass before Apply. Reuse the same credential for every share — do not create duplicates.

Exclude application-managed folders. On a QNAP running Surveillance Station, skip all QVRPro* folders — QVRProRecording is unbounded video, and QVRProDB is a live database that may not restore cleanly from a file-level copy. Same logic applies to any app-managed data store on a NAS.

Step 6 — Filters tab

Leave default unless there is a documented reason to exclude specific file types.

Step 7 — Add, run, verify

  1. Add to save the plan
  2. Run it manually
  3. Confirm it captured actual files — check the backed-up size against the known share size. A plan that reports success with 0 bytes has silently failed.
  4. Restore-test a file
  5. Document in IT Glue: plan name, mover endpoint, NAS IP, shares in scope, credential location, schedule

Per page 1421: the ticket stays open until the restore test is complete and documented.

Troubleshooting

Symptom Cause Fix
Test fails, password is correct Auth scoped to domain instead of device Put . in the Domain field
Test fails, cached session Stale SMB session on the mover net use * /delete on the mover, retry
Test fails from a domain controller UniFi Drive / some NAS require NTLMv2; DC LmCompatibilityLevel mismatch See System Error 86 (page 3818)
Job succeeds but backs up nothing NAS user lacks read permission on the share Verify share-level permission for the account
Job fails nightly, no pattern Mover endpoint sleeping Confirm power options; set OS power plan to never sleep
Cloud storage climbing unexpectedly App-managed folder (video, DB) included in scope Remove from target list
No local restore available Expected — plan type is cloud-only Add HBS3 sync to a local NAS if fast local restore is needed
Back to top