NAS OPERATIONS

NAS Deployment, Shares, Permissions and Capacity Playbook

Build a NAS around user access, data ownership, backup and growth instead of creating one giant share with one admin account.

Book 4 | Chapter 3

Chapter opening

Chapter 3 moves from the course overview into nas deployment, shares, permissions and capacity. The aim is not to memorise product menus or commands. The reader should understand what problem the technology solves, how it fits into the wider storage technical textbook, what normal operation looks like, and how to prove the result in the field.

The previous chapter introduced raid, storage performance and resilience playbook. This chapter continues the sequence by focusing on nas deployment, shares, permissions and capacity playbook, so the reader can connect the architecture to a more specific operational problem.

Storage textbookChapter 3

Learning objectives

  • Explain the main purpose of NAS Deployment, Shares, Permissions and Capacity in plain language.
  • Distinguish capacity, performance, resilience and backup instead of treating them as the same requirement.
  • Use evidence to separate a design problem from a configuration or physical fault.
  • Describe the business impact of a failure and the evidence required for handover.

Why this matters in a real company

Storage is where company files, databases and virtual machines live. The business impact is not only capacity: performance, resilience, backup and recovery determine whether data remains usable when something fails.

Course: Storage Technical Textbook

PLAIN ENGLISH

Technical terms used in this chapter

You do not need to memorise the jargon first. Understand what each term does and why somebody running a company would care about it.

Throughput

Throughput

The amount of useful data moved in a period of time.

In everyday business: It helps describe how fast large backups, files or storage transfers can complete.

Snapshot

Snapshot

A point-in-time storage or VM state used for short-term rollback depending on the platform.

In everyday business: It can quickly undo a bad change, but it is not automatically an independent backup.

Latency

Latency

The delay before an operation or packet completes.

In everyday business: Users experience high latency as slowness even when headline bandwidth looks good.

Volume

Container Volume

Persistent storage kept separately from the short-lived container filesystem.

In everyday business: Company data can survive when an application container is replaced.

Backup

Backup

An independent recoverable copy of data or system state.

In everyday business: It is the safety net for deletion, corruption, ransomware, hardware loss or major mistakes.

LACP

Link Aggregation Control Protocol

A protocol that combines compatible Ethernet links into one logical bundle.

In everyday business: It can add capacity and keep a connection alive if one member link fails.

RAID

Redundant Array of Independent Disks

A method of combining drives for capacity, performance and/or tolerance of certain drive failures.

In everyday business: A failed disk does not always mean immediate data loss, but RAID is not a backup.

ACL

Access Control List

A list of rules that says which network traffic is allowed or blocked.

In everyday business: Like a security guard checking a list at a door.

See the complete plain-English glossary

BUSINESS TRANSLATION

What this means outside the server room

This topic affects where company data lives, how fast applications respond and whether the business can continue after hardware or data problems.

RAID

What it means: RAID combines several drives so the storage system can keep operating through certain drive failures, depending on the RAID level.

In normal business language: Think of RAID as keeping the business open when one filing cabinet drawer breaks. It helps availability, but it does not protect you if somebody deletes the wrong folder, malware encrypts the files, or the whole building is lost.

Why the decision matters: Use RAID to reduce downtime from disk failure, and use backup for recovery from deletion, corruption, ransomware and larger disasters.

Virtual Machine

What it means: A virtual machine is a software-defined computer with its own operating system, memory, CPU allocation, disks and network interfaces.

In normal business language: It behaves like a separate server even though several VMs may share one physical machine.

Why the decision matters: VMs are useful for separating roles such as domain control, file sharing and applications while keeping management and recovery flexible.

Backup

What it means: A backup is an independent recoverable copy of data or system state.

In normal business language: Think of it as having a duplicate of important company records stored safely away from the live filing cabinet.

Why the decision matters: A backup only counts if it can be restored. Test recovery, not just backup completion.

Snapshot

What it means: A snapshot is a point-in-time state of a storage volume or VM on the same platform.

In normal business language: It is like a quick undo point inside the same office. Very useful for rolling back a mistake, but not enough if the whole storage system is lost.

Why the decision matters: Use snapshots for fast rollback, but keep independent backups for real disaster recovery.

NAT

What it means: NAT changes IP addresses as traffic crosses a network boundary.

In normal business language: It is similar to a company switchboard: many internal extensions can share one public number.

Why the decision matters: NAT helps with address use and publishing services, but it is not a substitute for firewall security.

NAS

What it means: NAS is network file storage, usually shared with protocols such as SMB or NFS.

In normal business language: It is a central company filing cabinet that many staff can access over the network.

Why the decision matters: NAS is a good fit for shared files, backups and general file services, provided permissions, backup and capacity are planned.

3.1 Start with data ownership

Define departments, applications and owners before creating shares. A share named "Data" that everyone can modify becomes difficult to secure, audit and migrate.

Share design

  • Use meaningful share names aligned to business ownership.
  • Grant access to groups, not individual users where possible.
  • Separate read-only reference data from collaborative write data.
  • Separate backup repositories from ordinary user shares.
  • Document service accounts and applications that depend on a share.

Permissions

Use the principle of least privilege. Avoid giving broad administrative rights to solve a file-access problem. When an inherited permission behaves unexpectedly, trace the effective permission from group membership, share permission and filesystem ACL rather than adding another allow.

Capacity planning

Plan usable capacity after RAID, filesystem overhead, snapshots and retention. Track growth rate. A volume that is nearly full can suffer operational problems even though the RAID itself is healthy.

Snapshots are not a complete backup

Snapshots can provide fast point-in-time recovery on supported filesystems, but they remain dependent on the storage system. Keep an independent backup for events that affect the NAS itself.

Data scrubbing

Synology documents data scrubbing as a maintenance process that can include filesystem checksum verification and RAID consistency work on supported configurations. Schedule it according to the model, workload and vendor guidance, and do not start heavy maintenance blindly during peak production.

Commissioning

  1. Create storage pool and volume.
  2. Create groups and shares.
  3. Apply least-privilege access.
  4. Test user read/write and denied access.
  5. Configure snapshots/backup.
  6. Configure alerts.
  7. Test restore from backup, not only backup completion.

Client benefit

A properly structured NAS makes access predictable, reduces accidental exposure, supports growth and makes restore procedures testable before a real incident.

3.2 Identity integration

If the NAS joins a directory service, define which directory groups map to which shares. Test a normal user, a privileged user and a user who should be denied. Do not validate permissions only with an administrator account.

SMB/NFS considerations

SMB and NFS use different identity and permission models. When the same data is exposed through multiple protocols, verify how UID/GID, ACLs, ownership and locking interact on the chosen NAS platform.

Capacity alerts

Set warning thresholds early enough that growth can be managed before a volume is critically full. Capacity planning should include snapshot retention, backup repositories, application growth and expansion method.

Drive replacement

For a degraded redundant pool, identify the failed drive by slot and serial information before removal. Replace only what the vendor procedure calls for, then monitor rebuild/repair to completion before removing another member.

3.3 SMB share design example

A useful departmental design might separate Finance, Projects, Public-Read and Backups rather than creating one root share with folders beneath it. This allows different snapshot schedules, quotas, permissions and backup policies by business purpose.

Quotas

Quotas can prevent one user or team from consuming all available capacity. They are an operational control, not a substitute for monitoring. Set them from business expectations and leave enough space for snapshots, system metadata and growth.

Recycle bin and previous versions

Where the platform supports them, these features help with routine accidental deletion. They do not replace protected snapshots or backup because users, malware or administrators may still affect the same storage system.

NAS network design

For high-throughput NAS, verify link speed, LACP or SMB multichannel support where applicable, switch uplink capacity and client capability. More NAS ports do not automatically make one file transfer faster. The protocol and host implementation determine how multiple links are used.

Maintenance window

Scrubbing, RAID repair and backup can compete for disk and CPU resources. Schedule intensive maintenance with knowledge of production workload and monitor application latency while it runs.

WORKED BUSINESS SCENARIO

Scenario: storage is online, but the business says it is slow

A storage system has free capacity and all disks show healthy, yet accounting reports are taking much longer and VM backups are overlapping into business hours.

What the chapter teaches us: Capacity and health LEDs do not prove performance. The investigation must separate application delay, host queues, network path, controller/cache behaviour and media performance.

Think it through

  1. Which measurements distinguish latency from throughput?
  2. Could the network be the bottleneck even when the array is healthy?
  3. What baseline would help prove whether the problem is new?
PRACTICAL WORK

Hands-on lab

Document a lab storage path from application to virtual or physical disk. Record usable capacity, RAID layout, network path if any, and backup destination.

Troubleshooting exercise

Storage is slow. Separate application, host queue, network, controller or cache and media metrics before replacing drives.

Chapter field checklist

  • I can explain the subject without relying only on acronyms.
  • I can draw or describe the main traffic, storage, power or service path.
  • I know what normal operation should look like.
  • I know which logs, counters or test results prove the result.
  • I can explain the business impact if this component fails.
  • I would document the final configuration and evidence at handover.

Chapter summary

NAS Deployment, Shares, Permissions and Capacity Playbook should now be understood as a business service with a technical implementation, not simply a collection of commands or product names. The important habit is to know the purpose, understand the dependencies, measure the result and document what was proven.

END OF CHAPTER

Review questions

  1. Explain the subject in plain language to a business owner.
  2. List the main dependencies that must be healthy before this service can work.
  3. Describe one realistic failure and the first three pieces of evidence you would collect.
  4. Explain what should be documented at handover.

A good answer should explain the reason, not only repeat a product name or command.

Technical references

Use the current project specification and the exact product documentation for the installed equipment. These references support the technical principles used in this guide.