4.2 Network Attached Storage Protocols, Shares & Permissions

Network Attached Storage Protocols, Shares & Permissions

Network Attached Storage (NAS) provides file-level data access to a heterogeneous network of clients over standard IP/Ethernet infrastructures. Unlike block storage systems where the host operating system controls volume partitioning and file system formatting, a NAS appliance owns, manages, and formats the underlying file system. The storage appliance is responsible for directory hierarchy traversal, metadata indexing, concurrent multi-user file locking, and protocol translation. Mastering enterprise NAS requires deep technical comprehension of the Network File System (NFS) and Server Message Block (SMB) protocol stacks, export and share security policies, and the complex mechanics of multi-protocol permission reconciliation.

---

1. Network File System (NFS) Protocol Evolution

The Network File System (NFS), originally developed by Sun Microsystems, is the foundational open standard for distributed file sharing in UNIX, Linux, and enterprise virtualization environments (such as VMware vSphere ESXi NFS datastores).

+-------------------------------------------------------------------------+
|                        NFS PROTOCOL EVOLUTION                           |
+-----------------------+-----------------------+-------------------------+
| ATTRIBUTE             | NFS VERSION 3 (RFC 1813)| NFS VERSION 4.x (RFC 7530)|
+-----------------------+-----------------------+-------------------------+
| Connection State      | Stateless             | Stateful                |
| Primary Network Port  | Portmapper 111 + dyn  | Single well-known 2049  |
| File Locking          | External NLM daemon   | Native in protocol      |
| Remote Mounting       | External rpc.mountd   | Integrated pseudo-fs    |
| Network Efficiency    | Single RPC per op     | Compound RPC requests   |
| Security Mechanism    | Client UID/GID trust  | Native Kerberos (GSS)   |
| Multi-Node Scale-Out  | Client-side multipath | pNFS (RFC 5661)         |
+-----------------------+-----------------------+-------------------------+

NFS Version 3: Stateless Architecture & Auxiliary Daemons

NFSv3 represents a purely stateless protocol. The NFS server does not maintain client session state, open file handles, or active cursor positions between operations. Each RPC request is self-contained and must supply full authentication credentials and file handle parameters.

Because the core NFSv3 protocol handles only basic file read, write, and lookup primitives, it depends on an array of external Open Network Computing Remote Procedure Call (ONC RPC) auxiliary services and daemons:

1. portmapper / rpcbind (TCP/UDP Port 111): When an auxiliary daemon starts, it registers a dynamically assigned high-order port with rpcbind. When a client initiates a mount, it first contacts rpcbind on port 111 to look up which dynamic ports are currently servicing the required RPC programs.
2. rpc.mountd: Processes client mount requests, validates export access rules (client IP/subnet verification), and returns the initial root file handle.
3. Network Lock Manager (NLM / rpc.lockd): Because NFSv3 is stateless, file locking cannot be handled natively. NLM provides advisory file locking across network clients.
4. Network Status Monitor (NSM / rpc.statd): Works alongside NLM to track client and server reboots. When a server restarts, rpc.statd notifies clients so they can attempt to reclaim their locks from NLM.

Operational Challenges of NFSv3

• Firewall Traversal: Because rpc.mountd, rpc.lockd, and rpc.statd bind to dynamically negotiated RPC ports, securing NFSv3 traffic through enterprise firewalls requires locking daemons to static ports via complex kernel configuration.
• Stale File Handles & Orphaned Locks: If a client abruptly loses network connectivity while holding an NLM file lock, the server may retain the lock indefinitely. Conversely, if the server reboots without persistent NSM state, clients experience stale lock errors requiring manual administrative intervention.

NFS Version 4, 4.1 & 4.2: Modern Stateful Architecture

NFSv4 (RFC 7530), NFSv4.1 (RFC 5661), and NFSv4.2 (RFC 7862) completely modernize the file sharing architecture, abandoning statelessness in favor of an integrated, stateful connection model.

Key Architectural Improvements

• Single Port Consolidation (TCP Port 2049): All file sharing services—including file system mounting, stateful locking, directory browsing, and data transfer—operate exclusively across a single well-known port: TCP 2049. Auxiliary daemons (rpcbind, mountd, lockd, statd) are completely eliminated, greatly simplifying firewall policies.
• Compound RPC Requests: In NFSv3, opening a file, reading data, and checking attributes requires multiple round-trip network hops (e.g., LOOKUP, ACCESS, OPEN, READ, GETATTR). NFSv4 introduces compound RPCs, grouping multiple sequential operations into a single network packet. The client sends one request, and the server executes the compound sequence locally, dramatically reducing round-trip latency over high-latency WAN or campus networks.
• Integrated Stateful Locking & Client Leases: File locking (byte-range locks, share reservations) is integrated directly into the protocol. The server issues timed client leases. Clients periodically renew their leases via background heartbeats. If a client fails, its lease expires, and the server cleanly releases all associated locks automatically.
• Pseudo-Filesystem Namespace: Rather than forcing clients to mount disjointed physical paths (e.g., /vol/storage_pool1/data/finance), an NFSv4 server exports a single unified pseudo-filesystem rooted at /. Subordinate exports appear as standard nested subdirectories within this virtual root namespace, allowing clients to mount the entire storage namespace using a single mount point.
• Native Kerberos Security (RPCSEC_GSS): Replaces insecure client-asserted UNIX UIDs with cryptographically verified Kerberos tickets across three distinct security levels:
  • krb5: Cryptographic authentication of user identities.
  • krb5i: Authentication plus cryptographic integrity checking (SHA-based hashing per packet to prevent tampering or man-in-the-middle attacks).
  • krb5p: Authentication, integrity, and full payload privacy (end-to-end AES encryption of all data in transit).

Parallel NFS (pNFS - NFSv4.1)

Traditional NFS forces all client I/O to pass through a single storage controller head, creating a massive bandwidth bottleneck in large clusters. NFSv4.1 introduces Parallel NFS (pNFS), which decouples the control plane from the data plane:

• Metadata Server (MDS): Handles namespace operations, directory lookups, file creation, and authorization.
• Data Servers (DS): Highly distributed storage nodes housing the actual file payloads.
• Operation: When a client requests a file, the MDS returns a Layout, which contains direct mapping instructions detailing which Data Servers hold the file's stripe fragments. The client then streams reads and writes directly and in parallel to multiple Data Servers simultaneously across block (FC/iSCSI), file (NFS), or object backends, scaling throughput linearly.

NFSv4.2 Advanced Enterprise Features

• Server-Side Copy (SSC): Enables a client to copy or clone a file between two locations on the storage array without reading the data across the network and writing it back, reducing multi-gigabyte file cloning times to seconds.
• Sparse Files: Adds native support for hole-punching and querying unallocated regions within sparse virtual machine disks, optimizing storage efficiency.
• Application Data Blocks (ADB): Allows database engines to communicate specific block sizing and layout requirements directly to the storage controller.

---

2. NFS Export Configuration & Security Options

Storage administrators expose storage directories to network clients by defining NFS Export Policies (configured via /etc/exports in Linux or via graphical management consoles in enterprise arrays such as HPE Alletra MP or StoreEasy).

+-------------------------------------------------------------------------+
|                        NFS EXPORT SECURITY MATRIX                       |
+-------------------+-----------------------------------------------------+
| OPTION            | BEHAVIOR & ARCHITECTURAL IMPACT                     |
+-------------------+-----------------------------------------------------+
| ro / rw           | Grants read-only or read-write access to the export |
| sync              | Acknowledges writes ONLY after data hits non-volatil|
|                   | storage media. Zero data loss on power failure.     |
| async             | Acknowledges writes while data sits in volatile RAM.|
|                   | High performance, but risks corruption on crash.    |
| root_squash       | DEFAULT. Remaps client UID 0 (root) to nobody       |
|                   | (UID 65534). Protects array from client superusers. |
| no_root_squash    | PRESERVES client UID 0. Grants superuser privileges |
|                   | on the array. Required for ESXi NFS datastores.     |
| all_squash        | Remaps ALL incoming client UIDs to anonymous user.  |
| anonuid / anongid | Explicitly assigns UID/GID for squashed accounts.   |
+-------------------+-----------------------------------------------------+

The Critical Mechanics of Root Squashing

Because UNIX systems historically trust the client operating system to report user identities, a user logged into a client machine with local root credentials (UID 0) could theoretically create, modify, or delete any system file on an NFS export.

• root_squash (Enterprise Default): When a client's root user (UID 0) accesses the export, the storage controller intercepts the request and dynamically remaps the UID to an unprivileged anonymous account (commonly nobody or UID 65534). This prevents rogue client administrators from altering permissions or accessing other users' confidential data.
• no_root_squash (High-Risk Exception): Completely disables root remapping. If a client connects as UID 0, the storage array executes the operation with full superuser administrative authority over the file system.
  • Mandatory Use Case: VMware vSphere ESXi NFS Datastores. When an ESXi hypervisor mounts an NFS volume to store virtual machine disks (VMDKs), the ESXi kernel operates as UID 0. If root_squash is enabled, ESXi cannot create VMDK files or manipulate lock files, causing immediate datastore mounting failures. Therefore, ESXi datastores strictly require no_root_squash.
  • Mandatory Use Case: Enterprise Backup Agents. Centralized backup engines requiring raw access to preserve native file ownership across all directories require no_root_squash.
  • Security Warning: Exposing an export configured with no_root_squash to general corporate subnets is a severe security vulnerability. Such exports must always be strictly isolated to dedicated management or storage VLANs using CIDR subnet restrictions (e.g., /vol/esx_ds01 192.168.20.0/24(rw,sync,no_root_squash)).

---

3. Server Message Block (SMB / CIFS) Protocol Evolution

The Server Message Block (SMB) protocol is the native network file sharing protocol for Microsoft Windows environments, providing client access to files, printers, and inter-process communications (named pipes).

+-------------------------------------------------------------------------+
|                        SMB PROTOCOL DIALECTS                            |
+-------------+-----------------------------------------------------------+
| DIALECT     | KEY CAPABILITIES & ENTERPRISE ADVANCEMENTS                |
+-------------+-----------------------------------------------------------+
| SMB 1.0     | Legacy, chatty, weak integrity; exploited by EternalBlue.  |
| (CIFS)      | MUST BE COMPLETELY DISABLED IN ENTERPRISE NETWORKS.       |
+-------------+-----------------------------------------------------------+
| SMB 2.0/2.1 | Credit-based flow control, large MTU support (64KB+),     |
|             | client-side opportunistic leasing, request pipelining.    |
+-------------+-----------------------------------------------------------+
| SMB 3.0/3.02| SMB Multichannel (link aggregation/failover), SMB Direct  |
|             | (RDMA over RoCE/iWARP), Transparent Failover (CA shares). |
+-------------+-----------------------------------------------------------+
| SMB 3.1.1   | Mandatory Pre-authentication Integrity (SHA-512), native  |
|             | AES-128-GCM and AES-256-GCM encryption, cluster fencing. |
+-------------+-----------------------------------------------------------+

Enterprise Capabilities of SMB 3.x

SMB 3.0, 3.0.2, and 3.1.1 transformed SMB from a simple desktop office file sharing protocol into a mission-critical, enterprise-grade storage transport capable of supporting high-transaction workloads like Microsoft Hyper-V virtualization and Microsoft SQL Server databases.

1. SMB Multichannel

• Dynamic Aggregation & Redundancy: If a client and a storage server have multiple network paths (e.g., dual 10GbE/25GbE network adapters, or a single adapter supporting Receive Side Scaling [RSS]), SMB Multichannel automatically discovers the paths and bonds them into a single high-bandwidth logical session.
• Zero Switch-Side Configuration: Unlike traditional Link Aggregation Control Protocol (LACP) or 802.3ad trunking, which requires complex physical switch port channel configuration, SMB Multichannel operates purely at the application layer. If an interface drops, SMB Multichannel dynamically shifts I/O to surviving links without disconnecting active applications.

2. SMB Direct (SMB over RDMA)

• Microsecond Latency & Zero CPU Overhead: SMB Direct leverages Remote Direct Memory Access (RDMA) networking over standard Converged Ethernet (RoCEv2 - RDMA over Converged Ethernet) or iWARP adapters.
• Memory-to-Memory Transfers: Storage read and write operations bypass the host operating system's TCP/IP stack, kernel buffers, and CPU interrupt processing entirely. Data is transferred directly from client application memory into storage controller memory. This delivers sub-millisecond latencies and high throughput comparable to dedicated Fibre Channel SANs, while freeing up host CPU cores for application processing.

3. Transparent Failover (Continuous Availability Shares)

• Standard SMB connections terminate if an active storage controller reboots, causing application timeouts and database dismounts.
• SMB 3.x introduced Continuously Available (CA) File Shares. When deployed across a clustered storage array, client nodes establish stateful bindings with redundant controllers. If Controller A fails or undergoes software maintenance, Controller B seamlessly assumes the client session state, active file locks, and open file handles without application disruption.

4. End-to-End Encryption & Pre-Authentication Integrity

• SMB Encryption: Protects sensitive enterprise data against eavesdropping on untrusted networks by encrypting payloads using hardware-accelerated AES-128-GCM or AES-256-GCM algorithms. Encryption can be enforced globally across the array, per-share, or per-client session without requiring complex IPsec or VPN tunnels.
• Pre-Authentication Integrity (SMB 3.1.1): Uses SHA-512 cryptographic hashing to authenticate the initial protocol negotiation and session setup phases, completely eliminating man-in-the-middle protocol downgrade attacks.

---

4. Permission Paradigms: Windows NTFS ACLs vs. POSIX Permissions

Managing access control across enterprise NAS shares requires understanding the architectural divide between Windows security descriptors and UNIX/Linux permissions.

+-------------------------------------------------------------------------+
|                     PERMISSION PARADIGMS COMPARED                       |
+------------------------------------+------------------------------------+
| WINDOWS NTFS DISCRETIONARY ACLs    | UNIX / LINUX POSIX PERMISSIONS     |
+------------------------------------+------------------------------------+
| Fine-grained Access Control Entries| 9 basic mode bits (rwxrwxrwx)      |
| (ACEs) supporting 13 discrete rights| for Owner, Group, and Other.       |
| Explicit Allow and Deny permissions| Special bits: setuid, setgid,      |
| Deny ACEs take precedence over Allow| sticky bit (restricted deletion).  |
| Object-oriented inheritance flags  | Extended POSIX draft ACLs support  |
| (Container Inherit, Object Inherit)| named users/groups, but lack       |
| Based on variable-length SIDs      | Windows inheritance flags.         |
+------------------------------------+------------------------------------+

Windows NTFS Access Control Lists (DACLs)

Windows NTFS security is evaluated using Discretionary Access Control Lists (DACLs) composed of individual Access Control Entries (ACEs) bound to Active Directory Security Identifiers (SIDs):

• 13 Granular Permissions: Traverse Folder / Execute File, List Folder / Read Data, Read Attributes, Read Extended Attributes, Create Files / Write Data, Create Folders / Append Data, Write Attributes, Write Extended Attributes, Delete Subfolders and Files, Delete, Read Permissions, Change Permissions, Take Ownership.
• Evaluation Order: Windows security evaluates permissions in a strict sequence: Explicit Deny → Explicit Allow → Inherited Deny → Inherited Allow. If no matching Allow ACE is found, access is implicitly denied.
• Inheritance Flags: Permissions propagate down folder trees using specific inheritance attributes: CI (Container Inherit - applies to subfolders), OI (Object Inherit - applies to files), and IO (Inherit Only - applies only to subordinates, not the container itself).

POSIX File Permissions

Traditional UNIX/Linux file systems enforce security using a compact 12-bit mode field:

• Owner / User (u): Read (4), Write (2), Execute (1).
• Group (g): Read (4), Write (2), Execute (1).
• Other / World (o): Read (4), Write (2), Execute (1).
• Special Bits: setuid (bit 4000 - executes with file owner privileges), setgid (bit 2000 - executes with group privileges and inherits parent directory group on creation), and sticky bit (bit 1000 - prevents non-owners from deleting files in a shared directory, commonly used on /tmp).

---

5. Multi-Protocol File Sharing Architectures & Challenges

Enterprise environments frequently require multi-protocol file sharing, where a single unified file repository must be accessed simultaneously by Windows clients over SMB and Linux clients over NFS.

+-------------------------------------------------------------------------+
|               MULTI-PROTOCOL RECONCILIATION ARCHITECTURE               |
+------------------------------------+------------------------------------+
| CHALLENGE DOMAIN                   | ARCHITECTURAL RESOLUTION           |
+------------------------------------+------------------------------------+
| 1. Identity Mapping                | Map Windows SIDs to 32-bit         |
|    (AD SIDs vs. UNIX UIDs/GIDs)    | UIDs/GIDs using RFC 2307 LDAP attrs|
+------------------------------------+------------------------------------+
| 2. Permission Synchronization      | Map NTFS granular DACLs to NFSv4   |
|    (NTFS ACLs vs. POSIX mode bits) | ACLs or synthetic POSIX mode bits  |
+------------------------------------+------------------------------------+
| 3. Cross-Protocol Locking          | Arbitrate between stateful SMB     |
|    (SMB oplocks vs. NFS locks)     | leases and NFS advisory/mand locks |
+------------------------------------+------------------------------------+
| 4. Filename Semantics              | Case-insensitive preservation      |
|    (Case-sensitive vs. insensitive)| with hash collision detection      |
+------------------------------------+------------------------------------+

1. Identity Mapping: Active Directory & RFC 2307

• The Conflict: When a Windows user logs in, Active Directory issues a Kerberos ticket whose authorization data carries the user's SIDs (e.g., S-1-5-21-3623811015-...-1001). When a Linux user accesses an NFS share, the client passes a 32-bit numeric UID (e.g., 1005) and GID (e.g., 2000). If a Windows user creates a file, the storage array must determine which UNIX UID owns it, and vice versa.
• The Resolution (RFC 2307): Enterprise NAS arrays integrate with Active Directory using the RFC 2307 schema extension. Active Directory user and group accounts are populated with UNIX attributes (uidNumber, gidNumber, and loginShell). When a Windows user accesses the NAS, the storage controller queries Active Directory via LDAP, retrieves the user's uidNumber, and binds the Windows SID and UNIX UID into a single unified security identity.

2. Permission Synchronization: Security Styles

Enterprise NAS arrays (such as HPE StoreEasy or multi-protocol storage systems) allow administrators to configure the Security Style of a shared volume:

• NTFS Security Style: Windows NTFS DACLs are the authoritative permission model. Even when a Linux client accesses the file over NFS, the storage array evaluates the request against the Windows ACL. The array translates POSIX chmod or chown requests into synthetic Windows ACE updates or rejects them if they violate the DACL.
• UNIX Security Style: POSIX mode bits or NFSv4 ACLs are authoritative. When a Windows client attempts to view file properties over SMB, the storage array generates a synthetic Windows ACL derived directly from the UNIX mode bits (e.g., converting mode 755 into Read/Execute for Everyone and Full Control for the Owner).
• Unified / Mixed Security Style: The array dynamically tracks whichever protocol made the most recent permission modification. While highly flexible, mixed security styles can lead to confusing administrative behavior if Windows administrators set complex DACLs that are subsequently flattened by a Linux user running chmod 644.

3. Cross-Protocol Locking Arbitration

Windows SMB relies heavily on client-side opportunistic locks (oplocks) and file leases, allowing a Windows workstation to cache file reads and writes locally in RAM. In contrast, NFS clients issue direct read/write operations to the array.

• If an NFS client attempts to write to a file that is currently cached and leased by an SMB client, the storage array must pause the NFS request, transmit an oplock break notification to the SMB client, wait for the SMB client to flush its dirty memory buffers back to the array, revoke the lease, and only then allow the NFS write to proceed.

4. Filename Case Sensitivity

• UNIX/Linux: File systems are strictly case-sensitive. The files Report.pdf, report.pdf, and REPORT.PDF represent three completely distinct files within the same directory.
• Windows: File systems are case-insensitive but case-preserving. Windows views Report.pdf and report.pdf as the exact same file.
• Multi-protocol storage controllers enforce case-preserving lookups for Windows clients while maintaining case uniqueness for UNIX clients, logging warnings or utilizing hash-mangled aliases if a Windows client attempts to access a directory containing conflicting filenames.

---

6. Comprehensive Protocol Matrix: NFS vs. SMB

---

7. Real-World Enterprise File Service Deployment Scenarios

Scenario 1: High-Performance VMware ESXi Datastore Cluster

• Requirement: A virtualized infrastructure team needs to mount an NFS datastore across 32 VMware ESXi hosts to run hundreds of enterprise virtual machines.
• Implementation Decisions: The storage architect deploys an NFS export configured with rw, sync, and no_root_squash over a dedicated, isolated 25GbE storage VLAN. The no_root_squash setting is mandatory because the ESXi VMkernel accesses datastores using UID 0. If root_squash were enabled, ESXi could not create or lock .vmdk disk descriptors, causing virtual machines to fail on boot. Network access is strictly restricted to the ESXi host VMkernel IP subnet to mitigate security risks.

Scenario 2: Cross-Platform Engineering CAD Design Center

• Requirement: An aerospace engineering firm employs 500 Linux workstations running computational fluid dynamics (CFD) simulation scripts and 300 Windows workstations running 3D CAD modeling software, all accessing a single 2 PB project repository.
• Implementation Decisions: The architect deploys an enterprise multi-protocol NAS solution integrating with Active Directory via RFC 2307 LDAP schema extensions. The project shares are configured with NTFS Security Style, making Active Directory DACLs the single point of truth. Linux users are assigned deterministic uidNumber and gidNumber values in Active Directory. Windows CAD clients utilize SMB 3.1.1 with SMB Multichannel for fast file loading, while Linux simulation worker nodes mount the shares via NFSv4.1 over TCP 2049 with Kerberos (krb5i), ensuring high-speed access and cross-protocol file lock integrity.

---

8. Common Exam Traps & Architectural Pitfalls

• Exam Trap 1: Enabling root_squash on VMware ESXi NFS Datastores. A classic exam scenario asks why newly provisioned ESXi hosts cannot format or create virtual machines on an NFS datastore. The answer is almost always that the storage export was inadvertently left with the default root_squash setting. ESXi requires no_root_squash to allow the hypervisor kernel (UID 0) to manage datastore files.
• Exam Trap 2: Believing SMB Multichannel Requires Switch Port Channel / LACP Configuration. Candidates often assume that SMB Multichannel requires configuring 802.3ad LACP or switch port bonding. SMB Multichannel operates entirely at the application protocol layer between the SMB client and server; it discovers and uses multiple network interfaces automatically without requiring any special switch configuration.
• Exam Trap 3: Confusing NFSv3 and NFSv4 Network Port Requirements. Questions frequently test firewall configuration for NFS. NFSv3 requires dynamic RPC port ranges managed by portmapper (port 111), while NFSv4 runs strictly across a single well-known port: TCP 2049.
• Exam Trap 4: Assuming SMB 1.0 Can Be Safely Kept for Backward Compatibility. In modern enterprise storage and security blueprints, SMB 1.0 is considered a critical security vulnerability because it lacks modern integrity and encryption protections and was the target of remote code execution exploits such as EternalBlue (MS17-010). Enterprise best practice requires completely disabling SMB 1.0 at both the storage controller and client levels.