Choosing between SMB and NFS
Both protocols provide shared access to files and directories. The right choice follows the clients, identity model, application semantics and availability design—not a simple Windows-versus-Linux label.
A shared file system changes who controls the namespace
With file storage, clients request named files and directories. The storage service manages the file system, permissions, locking and the relationship between paths and underlying capacity.
Paths and files
The application opens a path such as a share, export, directory or filename. It does not receive a raw disk or NVMe namespace.
The file system
The storage platform creates and maintains the namespace, metadata, permissions and space allocation behind the share.
Access policy
Directory services, user identities, export rules, ACLs and application behaviour must form one coherent design.
File storage is not a slower form of block storage. It is a different contract. A well-designed file service can simplify shared access, while a workload that expects its own disk or clustered block device should use a block protocol.
SMB fits rich user and application file services
SMB is a stateful network file-sharing protocol with authentication, file and record locking, change notification and extended file attributes. It is a natural fit for Windows estates and Active Directory-based access.
and applications
with ACLs and locks
- User home directories and departmental shares
- Active Directory-oriented permissions and group access
- Application data requiring Windows file semantics
- Cross-platform access when client compatibility is validated
NFS fits Unix, Linux and hypervisor workflows
NFS presents exported directories through an RPC-based file protocol. NFSv4.1 integrates locking into the protocol and adds sessions, stronger identity options and capabilities for multi-connection or parallel access designs.
or ESXi clients
with client policy
- Linux and Unix application data
- Shared technical, development and media datasets
- VMware NFS datastores on supported configurations
- Scale-out file services where client and namespace behaviour align
Compare the operating model—not only the protocol name
The protocol must match the client, authentication method, failure behaviour and application’s expectations for locking and metadata.
| Decision area | SMB | NFS | Design question |
|---|---|---|---|
| Typical clients | Windows users and applications; selected cross-platform clients | Linux, Unix, ESXi and selected application clients | Which operating systems and applications are actually certified? |
| Namespace | Shares, paths and Windows-oriented file semantics | Exports, mount paths and Unix-oriented file semantics | How does the application expect to address and rename data? |
| Identity | Commonly Active Directory users, groups and Windows ACLs | UID/GID, directory integration or Kerberos according to the design | Can every client resolve the same user and group consistently? |
| Locking and caching | Stateful locks, leases/oplocks and change notification | Version-dependent locking, caching and session behaviour | Does the workload rely on strict concurrent access semantics? |
| Security | Authentication, signing and encryption according to dialect and policy | Export controls plus the chosen RPC security mechanism | Are identity, encryption and administrative boundaries end-to-end? |
| Path resilience | Capabilities such as Multichannel require support and configuration at both ends | NFSv4.1 trunking or platform-specific multi-connection behaviour requires validation | What happens to open files and applications during a path or service failure? |
| VMware use | Not normally the primary protocol for a vSphere datastore | NFS 3 and NFS 4.1 are supported datastore models in appropriate vSphere configurations | Which NFS version and vSphere feature set is required? |
| Best starting point | Windows-centric collaboration and application shares | Linux/Unix data, technical workloads and VMware NFS datastores | Which client contract reduces operational complexity? |
Do not select by habit. “Windows means SMB” and “Linux means NFS” are useful starting points, not complete architecture decisions. Application certification, identity, lock behaviour and recovery requirements can change the result.
The same username must mean the same identity
Most difficult file-storage problems are not caused by media. They arise when clients, directories and storage services interpret users, groups and permissions differently.
- Define the authoritative identity source before creating shares or exports.
- Map Windows ACLs, POSIX permissions and group membership intentionally.
- Synchronise time, DNS and directory dependencies across the design.
- Test service accounts, nested groups and application-created files.
Identity path
Presenting one dataset simultaneously through SMB and NFS can introduce permission, naming and locking conflicts. Use a documented multiprotocol design rather than simply enabling both services.
Privileged identities are not automatically equivalent across operating systems. Define administrative access and ownership explicitly.
Protocol options cannot compensate for weak directory policy, unrestricted networks or untested recovery credentials.
NFS can present a shared VMware datastore without a block LUN
ESXi mounts an NFS export and uses it as a datastore. The storage system owns the file system and ESXi works with virtual-machine files through the NFS protocol.
- Validate the selected NFS version across every host.
- Use consistent server names, export paths and network configuration.
- Design redundant storage networks and test failure recovery.
- Check vSphere feature and version constraints before standardising on NFS 3 or NFS 4.1.
and VMkernel networking
on shared storage
A reachable share is not automatically a protected service
Protocol access, service failover, path resilience and data recovery are separate layers. Each requires its own design and test plan.
Client compatibility, authentication and file semantics.
Interfaces, switches, addressing and client reconnect behaviour.
Standalone, two-node HA or distributed scale-out architecture.
Snapshots, replication, retention and application-consistent recovery.
Test what happens to an open file, a mounted datastore and a running application—not only whether a server answers a ping after failover.
Begin with what the workload expects to mount
Start with SMB, then validate identity, ACLs, dialect and recovery behaviour.
Start with NFS, then validate version, identities, mount behaviour and locking.
Use block storage; let the host or cluster own the file system.
Different euroNAS platforms cover different operating models
The access protocol is only one selection dimension. Capacity, failure domain, management model and recovery objectives determine which platform is appropriate.
| Platform | File-service role | Availability model | Scaling model | Typical starting point |
|---|---|---|---|---|
| euroNAS Premium | SMB and NFS from a standalone storage server | Single-server design; external protection and recovery must match the requirement | Scale up within the selected server, including deployment as a Virtual Storage Appliance | Departmental, application and general-purpose file services |
| euroNAS HA Cluster | Highly available SMB and NFS services | Two-node automatic service failover using synchronous Mirror or a shared-storage model; asynchronous ZFS replication is a separate DR option | Scale up within the two-node HA architecture | Business-critical file services requiring automatic failover |
| eEKAS | Scale-out SMB and NFS services on distributed Ceph storage | Distributed data protection and service design across multiple nodes | Add qualified storage nodes without a fixed two-node boundary | Large or growing namespaces, distributed capacity and scale-out requirements |
| eEVOS | Consumes compatible external file services where required; not positioned here as a general-purpose file-storage target | Virtualisation, Backup & Disaster Recovery and compute availability belong to the eEVOS platform design | Compute nodes can be expanded according to the virtualisation architecture | Virtualisation platform using internal or external storage services |
euroNAS Premium
File, block and S3 services from one server or virtual appliance.
Premium details →HA Cluster
Automatic service failover for business-critical file and block services.
HA Cluster details →eEKAS
Distributed Ceph platform for scale-out file, block and object services.
eEKAS details →eEVOS
Virtualisation platform that consumes storage according to the selected architecture.
eEVOS details →Relate file access to the wider storage architecture
Standards and platform guidance
Protocol features and platform support change over time. Validate the complete client, operating-system, network and storage combination before deployment.
Microsoft SMB overview
Client/server operation, authentication, locking, attributes and change notification.
Open Microsoft guidance →VMware NFS support
Current platform notes for NFS 3 and NFS 4.1 datastores in vSphere environments.
Open Broadcom guidance →Design the file service around the workload
We can review client compatibility, identity, sharing, failover and protection objectives before a protocol or platform is selected.