Anyone moving classic Windows file services to AWS runs into the same question: how do you reproduce a file share structure that grew over a decade without reinventing it? Amazon FSx for NetApp ONTAP (FSxN) is the obvious answer, because the service brings the same ONTAP semantics that have been running in the data centre for years — including SMB shares, NTFS ACLs and snapshots in the Windows “Previous Versions” dialog.

This post is part 1 of a three-part series:

• Part 1 (this one): Building blocks, CIFS/SMB shares, snapshots and backup
• Part 2: NFS exports and export policies
• Part 3: Multiprotocol access to the same data set

All examples use the ONTAP CLI through the file system’s management endpoint.

Reference architecture

Windows clients reach shares that live on qtrees inside an NTFS volume. The snapshot policy feeds both the Previous Versions dialog and the SnapMirror relationship of policy type vault (SnapVault) to a second FSxN file system.

1. The three building blocks

None of the later decisions make sense without these three objects, so here they are — short and precise.

Storage Virtual Machine (SVM)

The SVM is the actual file server. It has its own network interfaces (LIFs), its own DNS name, its own Active Directory membership and its own CIFS and NFS servers. An FSxN file system can host several SVMs, and each SVM is a hard tenancy boundary: shares, export policies, user mappings and name services are all separate per SVM.

In practice that means: the separation between two business units that must not see each other’s data belongs at the SVM level — not in folder permissions.

FsxId0123456789abcdef0::> vserver show
FsxId0123456789abcdef0::> network interface show -vserver svm_prod -fields address,data-protocol

Volume

The volume is the unit of capacity and data management. Snapshots, tiering policy, storage efficiency, SnapMirror relationships and the security style all hang off the volume. The junction path mounts it into the SVM’s namespace, which is what makes it visible to clients in the first place.

FsxId0123456789abcdef0::> volume create -vserver svm_prod -volume vol_projects \
    -aggregate aggr1 -size 2TB -security-style ntfs \
    -junction-path /projects -policy default \
    -snapshot-policy sp_fileservices -percent-snapshot-space 10 \
    -tiering-policy auto -tiering-minimum-cooling-days 31

On FSxN all volumes of an HA pair sit on a single aggregate (aggr1); scale-out file systems use aggr1 through aggrN. Capacity planning at the aggregate level is therefore largely gone.

One number matters for the share layout: the default service limit is 500 volumes per file system — in large environments with many departments that arrives faster than you would think.

Qtree

A qtree is a logical container inside a volume — visible in the file system as a top-level directory, but to ONTAP it is a management object in its own right, with its own security style, export policy and quota. Each volume supports up to 4,995 qtrees, each with tailored permissions and security styles.

FsxId0123456789abcdef0::> volume qtree create -vserver svm_prod \
    -volume vol_projects -qtree finance \
    -security-style ntfs -oplock-mode enable

FsxId0123456789abcdef0::> volume qtree show -vserver svm_prod -volume vol_projects \
    -fields security-style,export-policy,oplock-mode

That is the real lever: using qtrees deliberately sidesteps the volume limit and removes the need for a limit increase. Instead of 300 small departmental volumes you manage a dozen volumes with dozens of qtrees each.

One side effect worth designing around: snapshots and SnapMirror operate at the volume level. All qtrees in a volume therefore share one snapshot schedule and one backup relationship. If a department needs different retention, give it its own volume.

Volume or qtree? A decision aid

Rule of thumb: anything that needs its own data management characteristics (backup rhythm, replication, retention) gets a volume. Anything that differs only in permissions and capacity gets a qtree.

Security style — the single most important decision

Every volume and every qtree has a security style that determines which permission model is authoritative:

• NTFS — Windows ACLs rule. The normal case for everything in this post.
• UNIX — mode bits or NFSv4 ACLs rule. Subject of part 2.
• Mixed — whichever client last set permissions determines the effective model.

On mixed, a clear recommendation: stay away unless you have a compelling reason. The style does not make permissions more flexible, only harder to reason about — six months into operations nobody can say which model currently applies to which directory. Multiprotocol access works fine with NTFS or UNIX as the style, which is exactly the topic of part 3.

Namespace and junction paths

Every SVM owns a root volume that spans the namespace. Data volumes are mounted into it via their junction path — /projects, /home, /app/data. Clients see one contiguous directory tree regardless of which volume the data physically lives on. A volume without a junction path is invisible to clients, no matter how correctly the share is configured.

FsxId0123456789abcdef0::> volume show -vserver svm_prod \
    -fields junction-path,policy,security-style,size,available

2. Prerequisites for CIFS

The SVM’s CIFS server has to be joined to the Active Directory domain. Three things must line up, and they are the usual suspects behind join failures: DNS resolution of the domain from the SVM subnet, reachable domain controllers (LDAP, Kerberos, SMB), and clock skew under five minutes.

FsxId0123456789abcdef0::> vserver cifs show -vserver svm_prod
FsxId0123456789abcdef0::> vserver cifs domain discovered-servers show -vserver svm_prod
FsxId0123456789abcdef0::> vserver services name-service dns show -vserver svm_prod

3. Creating and configuring shares

A share is a named entry point onto a path in the namespace — either a volume or a qtree:

FsxId0123456789abcdef0::> vserver cifs share create -vserver svm_prod \
    -share-name finance -path /projects/finance \
    -share-properties oplocks,browsable,changenotify,show-previous-versions,access-based-enumeration \
    -comment "Finance team - project storage"

The share properties that matter in practice:

• oplocks — client-side caching. On by default and desirable in nearly every case; turn it off only for database or application files with concurrent access.
• changenotify — the client is told about directory changes. On very large directories with a high rate of change this is a noticeable cost factor.
• access-based-enumeration (ABE) — users only see what they can actually access. It costs a little performance on directory listings but reduces both support load and curiosity.
• show-previous-versions — wires ONTAP snapshots into the Windows “Previous Versions” tab. More on that in section 6.

Reviewing and adjusting existing shares:

FsxId0123456789abcdef0::> vserver cifs share show -vserver svm_prod
FsxId0123456789abcdef0::> vserver cifs share properties add -vserver svm_prod \
    -share-name finance -share-properties access-based-enumeration

4. Permissions: share ACL and NTFS ACL

Effective access is the intersection of the share permission and the file ACL. Both layers need attention, and the default here is too generous: a new share gets Everyone / Full Control on the share ACL.

The common model keeps the share layer broad and does the fine-grained work in NTFS — but not on Everyone:

FsxId0123456789abcdef0::> vserver cifs share access-control delete -vserver svm_prod \
    -share finance -user-or-group "Everyone" -user-group-type windows

FsxId0123456789abcdef0::> vserver cifs share access-control create -vserver svm_prod \
    -share finance -user-or-group "CORP\FIN-Finance-RW" \
    -user-group-type windows -permission Change

FsxId0123456789abcdef0::> vserver cifs share access-control create -vserver svm_prod \
    -share finance -user-or-group "CORP\FIN-Finance-RO" \
    -user-group-type windows -permission Read

The available levels are No_access, Read, Change and Full_Control. Full_Control at the share level should stay reserved for an explicit administration group — regular user groups never need it.

Setting NTFS ACLs declaratively

NTFS ACLs are usually set from a Windows client. ONTAP can also manage them itself, which is considerably more attractive for reproducible deployments:

FsxId0123456789abcdef0::> vserver security file-directory ntfs create -vserver svm_prod \
    -ntfs-sd sd_finance -owner "CORP\Domain Admins"

FsxId0123456789abcdef0::> vserver security file-directory ntfs dacl add -vserver svm_prod \
    -ntfs-sd sd_finance -access-type allow -account "CORP\FIN-Finance-RW" \
    -rights modify -apply-to this-folder,sub-folders,files

FsxId0123456789abcdef0::> vserver security file-directory ntfs dacl add -vserver svm_prod \
    -ntfs-sd sd_finance -access-type allow -account "CORP\FIN-Finance-RO" \
    -rights read -apply-to this-folder,sub-folders,files

FsxId0123456789abcdef0::> vserver security file-directory policy create -vserver svm_prod \
    -policy-name pol_finance

FsxId0123456789abcdef0::> vserver security file-directory policy task add -vserver svm_prod \
    -policy-name pol_finance -path /projects/finance \
    -ntfs-sd sd_finance -security-type ntfs

FsxId0123456789abcdef0::> vserver security file-directory apply -vserver svm_prod \
    -policy-name pol_finance

Checking the effective permissions:

FsxId0123456789abcdef0::> vserver security file-directory show -vserver svm_prod \
    -path /projects/finance

5. Home directory shares

Instead of one share per user you define a single dynamic share. ONTAP resolves the variables at connection time — %w for the Windows user name, %d for the domain:

FsxId0123456789abcdef0::> vserver cifs home-directory search-path add -vserver svm_prod \
    -path /home

FsxId0123456789abcdef0::> vserver cifs share create -vserver svm_prod \
    -share-name %w -path %w \
    -share-properties oplocks,browsable,changenotify,homedirectory

When CORP\jsmith connects, they land on /home/jsmith. One share object, any number of users — and combined with user quotas, a very lean home directory solution.

6. Snapshots and backup

This is where FSxN makes its strongest case against a hand-built Windows file server: data protection is not an additional component, it is a property of the volume.

Defining a snapshot policy

A snapshot policy bundles several schedules, each with its own retention. The SnapMirror labels are the crucial part — without them a vault relationship cannot later pick out which snapshots to replicate:

FsxId0123456789abcdef0::> snapshot policy create -vserver svm_prod \
    -policy sp_fileservices -enabled true \
    -schedule1 hourly -count1 12 -snapmirror-label1 hourly \
    -schedule2 daily  -count2 14 -snapmirror-label2 daily \
    -schedule3 weekly -count3 8  -snapmirror-label3 weekly

FsxId0123456789abcdef0::> volume modify -vserver svm_prod -volume vol_projects \
    -snapshot-policy sp_fileservices -percent-snapshot-space 10

Twelve hourly, fourteen daily and eight weekly snapshots cover the typical file service need: a file overwritten by accident today, a folder deleted in the last fortnight, older states going back two months.

On capacity: snapshots only consume changed blocks. Ten percent snapshot reserve is a common starting point for office documents; on volumes with a high change rate, watch actual consumption and adjust.

FsxId0123456789abcdef0::> volume show -vserver svm_prod -volume vol_projects \
    -fields percent-snapshot-space,size-used-by-snapshots,snapshot-policy

FsxId0123456789abcdef0::> volume snapshot show -vserver svm_prod -volume vol_projects

Previous Versions for end users

With the share property show-previous-versions, snapshots appear directly in Windows Explorer under “Previous Versions”. A user restores an overwritten file themselves — no ticket, no waiting, no admin. In practice this is one of the strongest arguments in an end-user conversation.

If you also want the ~snapshot folder visible:

FsxId0123456789abcdef0::> vserver cifs share properties add -vserver svm_prod \
    -share-name finance -share-properties showsnapshot

Conversely you can hide it deliberately when users should not navigate the snapshot structure — the Previous Versions tab works regardless:

FsxId0123456789abcdef0::> vserver cifs share properties add -vserver svm_prod \
    -share-name finance -share-properties hide-snapshot

Restore at the storage layer

For the cases where self-service is not enough — an accidentally deleted directory tree, for example:

# Bring a single file back from a snapshot
FsxId0123456789abcdef0::> volume snapshot restore-file -vserver svm_prod \
    -volume vol_projects -snapshot daily.2026-09-19_0010 \
    -path /finance/Planning_2027.xlsx

# Roll the entire volume back to a snapshot
FsxId0123456789abcdef0::> volume snapshot restore -vserver svm_prod \
    -volume vol_projects -snapshot daily.2026-09-19_0010

The second command discards every change since the snapshot and deletes newer snapshots of the volume. It belongs in a documented procedure with four-eyes approval, not in day-to-day work.

SnapVault: SnapMirror with policy type vault

Snapshots live in the same volume as the production data. They are excellent against accidental deletion — and useless against the loss of the file system itself. That is what SnapVault is for: snapshots are transferred to a second FSxN file system and kept there longer than on the source.

First a clarification, because this regularly gets muddled: SnapVault is not a separate technology, it is a SnapMirror relationship whose policy carries the type vault. There is exactly one SnapMirror engine; the policy type determines the behaviour:

That is why every command in this section reads snapmirror ..., even where people colloquially say SnapVault. For long-term retention vault is the right type: it does not mirror the current state, it accumulates labelled recovery points.

The configuration follows a fixed order. The FSxN file systems must be peered first so they can replicate to each other, then the participating SVMs. The destination volume is created with volume type DP — that type is mandatory for a replication target. Next comes a SnapMirror policy of type vault whose rules use the SnapMirror label to control which snapshots are replicated and how long they are kept at the destination. Finally the relationship is created and initialised, with the first run transferring the complete source data.

Step 1 — peering (once per file system pair, at cluster and SVM level):

FsxId0123456789abcdef0::> cluster peer create -address-family ipv4 \
    -peer-addrs 10.30.1.10,10.30.2.10

FsxId0123456789abcdef0::> vserver peer create -vserver svm_prod \
    -peer-vserver svm_vault -peer-cluster FsxIdfedcba9876543210f \
    -applications snapmirror

Step 2 — destination volume of type DP (on the secondary file system):

FsxIdfedcba9876543210f::> volume create -vserver svm_vault \
    -volume vol_projects_vault -aggregate aggr1 -size 3TB -type DP

Step 3 — SnapMirror policy of type vault with label rules:

FsxIdfedcba9876543210f::> snapmirror policy create -vserver svm_vault \
    -policy pol_vault_fileservices -type vault

FsxIdfedcba9876543210f::> snapmirror policy add-rule -vserver svm_vault \
    -policy pol_vault_fileservices -snapmirror-label daily -keep 30

FsxIdfedcba9876543210f::> snapmirror policy add-rule -vserver svm_vault \
    -policy pol_vault_fileservices -snapmirror-label weekly -keep 26

The labels come from the snapshot policy above. The destination therefore holds 30 daily and 26 weekly states — roughly half a year of retention — while the source keeps only 14 and 8.

Step 4 — create and initialise the relationship:

FsxIdfedcba9876543210f::> snapmirror create \
    -source-path svm_prod:vol_projects \
    -destination-path svm_vault:vol_projects_vault \
    -policy pol_vault_fileservices -schedule daily

FsxIdfedcba9876543210f::> snapmirror initialize \
    -destination-path svm_vault:vol_projects_vault

Operational monitoring:

FsxIdfedcba9876543210f::> snapmirror show -destination-path svm_vault:vol_projects_vault
FsxIdfedcba9876543210f::> snapmirror show -fields state,status,lag-time,last-transfer-size

The lag-time field belongs in your monitoring. If it grows beyond the transfer interval, replication is falling behind the change rate.

Recovering a file from the vault works like any other snapshot restore — mount the destination volume read-only, or push data back with snapmirror restore.

How this differs from AWS Backup

FSxN volumes can additionally be protected through AWS Backup. Both routes have their place:

In regulated environments you often see both: the vault relationship for fast operational restores, AWS Backup for audit-proof retention outside the storage stack.

7. Day-to-day administration

Connected clients and sessions

FsxId0123456789abcdef0::> vserver cifs session show -vserver svm_prod
FsxId0123456789abcdef0::> vserver cifs session show -vserver svm_prod -instance

The session view shows user, client IP, protocol version, authentication method and open files — useful for answering who is locking a file, and for verifying that clients really are on SMB 3.x.

Open files and locks

FsxId0123456789abcdef0::> vserver locks show -vserver svm_prod -volume vol_projects
FsxId0123456789abcdef0::> vserver locks break -vserver svm_prod \
    -volume vol_projects -lif lif_prod_01 -path /projects/finance/plan.xlsx

Breaking locks has side effects — only after talking to the affected user.

Controlling capacity: tree quotas

Qtrees deliver their second big benefit together with quotas. Using ONTAP qtrees and tree quota policy rules, a single volume can be subdivided into logical workload boundaries with hard limits, plus soft limits and thresholds that generate alerts before enforcement kicks in. Enforcement happens at the storage layer, independent of the protocol in use:

FsxId0123456789abcdef0::> volume quota policy rule create -vserver svm_prod \
    -policy-name default -volume vol_projects \
    -type tree -target finance -disk-limit 500GB -threshold 450GB

FsxId0123456789abcdef0::> volume quota on -vserver svm_prod -volume vol_projects -foreground
FsxId0123456789abcdef0::> volume quota report -vserver svm_prod -volume vol_projects

After every rule change a volume quota resize is needed so the change takes effect without a full recalculation:

FsxId0123456789abcdef0::> volume quota resize -vserver svm_prod -volume vol_projects

Worth noting: the snapshot reserve does not count against the tree quota. A volume can fill up through snapshots while every quota is formally respected — which is why size-used-by-snapshots belongs in your monitoring just as much as the quota report.

8. Best practices in brief

1. Use the SVM as the tenancy boundary, not merely as a network endpoint.
2. Cut volumes along data management characteristics, qtrees along permissions and capacity — the snapshot schedule and SnapMirror relationship hang off the volume.
3. Choose the security style deliberately — NTFS throughout for pure Windows environments.
4. Remove Everyone / Full Control from new shares immediately.
5. Grant through AD groups, never through individual user accounts.
6. Enable ABE wherever directory names reveal something about projects.
7. Always set show-previous-versions — self-service restore visibly reduces support load.
8. Assign SnapMirror labels from day one, even if the vault relationship comes later.
9. Monitor lag-time, not just the state of the relationship.
10. Tree quotas with a threshold rather than bare hard limits — warn before you block.

Conclusion and what’s next

FSxN brings the full ONTAP model to AWS: SVM as tenant, volume as data management unit, qtree as the fine-grained container, SMB shares on top — and with snapshot policies plus a SnapMirror relationship of type vault, data protection that does not have to be bolted on afterwards. Once you understand these objects and how they inherit from each other, existing Windows share structures move across almost unchanged.

Part 2 looks at the same structure from the Linux side: NFS exports, export policies and how their rules are evaluated, NFSv3 versus NFSv4.1, and the mount options that actually matter in a Multi-AZ deployment.