Skip to main content
TRUENAS & NAS

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.

  1. 1Clients and identities
  2. 2Protocols and ACLs
  3. 3Authorised/unauthorised pilot
  4. 4Recovery and operations
Accept access through allowed and denied tests.

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

ObservationLikely cause / distinctionVerification
Login works but files do not openShare and dataset permissions may differ.Check effective ACLs/inheritance using test accounts.
NFS ownership appears differentUID/GID or identity mappings may differ.Compare identity resolution on client and server.
iSCSI connects but data corruptsMultiple uncoordinated writers may share a LUN.Stop writes and verify supported cluster/initiator design.

Acceptance checks

  1. Accept access through allowed and denied tests.
  2. Separate file and block consumers.
  3. Test groups, direct grants and inheritance.
  4. Check multiprotocol locking.
  5. Verify revocation in a fresh session.
  6. 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.

Enterprise IT Product Sales, Licensing and Deployment
Enterprise IT Project & Solution Scenarios
View all related content
Text on WhatsApp
Copied!