TrueNAS File and Storage Servers: SMB, NFS, iSCSI and ACLs
Separate file and block access; design access through identities, groups, share policies and client validation.
Content update:
Architecture and operating model
SMB and NFS expose files; iSCSI exposes block devices. Equal capacity does not imply equal ownership/consistency models. Evaluate SMB for team files, NFS for Unix/Linux and compatible hypervisors, and iSCSI for supported block consumers. Selection follows client/application requirements. Concurrent writes from ordinary hosts to one LUN can corrupt data without cluster-aware coordination.
Assess local users, AD, LDAP and supported directory integration separately. DNS and time are authentication dependencies. Group-based access can simplify departures, but direct grants and inheritance still need review. Separate backup, storage administration and department-user privileges.
Share permissions and filesystem ACLs jointly determine effective access. POSIX and NFSv4 ACLs differ; choose presets/inheritance for protocol and version. Recursive ACL changes can affect large trees. First test read, write, delete and rename on a small dataset using administrators, authorised users and unauthorised users.
Multiprotocol access can cause locking, UID/GID and ACL-semantic issues. Do not resolve access problems by broadly enabling NFS root mapping or SMB guest access. Restrict initiators, targets, LUNs and network access for block services; CHAP alone does not encrypt traffic. Separate management, user-file and storage trust boundaries.
Acceptance goes beyond connection: applications open files, concurrency locks correctly, revocation takes effect in a fresh session, and deleted files recover with appropriate ownership. Define logging retention/access. Customer file names, contents or keys require authorised review before sharing with support.
- 1Clients and identities
- 2Protocols and ACLs
- 3Authorised/unauthorised pilot
- 4Recovery and operations
Design parameters
- Access model
- Separate file protocols from block consumers and ownership.
- Identity dependency
- Check DNS, NTP, directories and group mappings.
- Effective ACL
- Test share, filesystem and inherited rights together.
- Network and client
- Verify protocol security, boundaries and client support.
Worked example
An illustrative finance dataset grants write access to Finance-RW and read access to Audit-RO. Finance creates files, audit reads without editing, and another department is denied. Test direct subfolder grants because removing group membership may not remove every access path.
Compare NFS and iSCSI for a VM datastore using equal small pilot workloads. Record snapshot coordination, remount after restart, latency and recovery. A file-copy speed test alone is insufficient datastore acceptance.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Login works but files do not open | Share and dataset permissions may differ. | Check effective ACLs/inheritance using test accounts. |
| NFS ownership appears different | UID/GID or identity mappings may differ. | Compare identity resolution on client and server. |
| iSCSI connects but data corrupts | Multiple uncoordinated writers may share a LUN. | Stop writes and verify supported cluster/initiator design. |
Acceptance checks
- Accept access through allowed and denied tests.
- Separate file and block consumers.
- Test groups, direct grants and inheritance.
- Check multiprotocol locking.
- Verify revocation in a fresh session.
- Check ownership and ACLs after restore.
Related concepts
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the actual runtime user, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Locks, waits and deadlocks
Concurrent operations use locks or versioning to preserve integrity. Long transactions can block others; a deadlock forms a cycle of mutual waits. The database may terminate one participant, requiring safe application retries. Examine blocked and blocking queries together. Arbitrarily reducing isolation can change consistency guarantees. Test shorter transactions, consistent access order and suitable indexes under the same workload.
Filesystem and storage layers
An application directory, mount point, logical volume and physical device belong to different layers. Inode exhaustion, read-only mounts and filesystem errors can stop writes even when space appears available. A snapshot often shares the same storage failure domain and is not an independent backup. Mount options and expansion methods depend on the filesystem. Verify mounts after reboot: writing to an unmounted directory can fill the wrong device.
Application consistency
A copy that boots does not prove application-data consistency. Operating-system caches, database logs and write ordering across disks or services affect the result. A crash-consistent copy resembles recovery after an unexpected shutdown; an application-consistent copy follows supported application preparation and write coordination. Validate transaction integrity, relationships between records and application behaviour after recovery, rather than only counting files. Confirm backup integration, application version and reported errors before assuming that consistency was achieved.
Primary documentation
Editorial method
Prepared by the Doz Technology technical team using official vendor documentation. Scenarios and calculations illustrate the method; they are not completed customer tests. Before implementation, verify versions, licences, client support, security conditions and rollback in your environment. Select solutions against existing products and workload requirements.
Related storage guides
TrueNAS Installation: Hardware, Versions and Safe Migration
Plan the storage role, hardware compatibility, management access and version migration alongside recovery.
Read the guideTrueNAS and ZFS: Pools, Vdevs, RAIDZ and Dataset Design
Separate usable capacity from raw disks; plan mirror/RAIDZ topology, dataset boundaries, snapshot growth and expansion together.
Read the guideTrueNAS: Snapshots, Replication and Backup Recovery
Design ZFS snapshots, local/remote replication and independent backups as distinct protection layers; measure RPO/RTO through restore tests.
Read the guideTrueNAS Performance and Maintenance: IOPS, ARC, Scrubs and Disk Health
Measure bottlenecks across clients, networking and disks; manage caches, scrubs, resilvers and updates alongside data safety.
Read the guideTrueNAS, OpenMediaVault, XigmaNAS and Unraid Comparison
Compare NAS choices by data model, disk topology, hardware compatibility, backup, operations and total cost.
Read the guideWe assess platform choice alongside your existing products, workloads and operational needs.