A TrueNAS system held roughly 4 TiB of data on a 5 TiB pool under one local user. The owner wanted a replacement user, access to the same files through SMB and FTP, privacy between users, and no copy because the pool had insufficient free space.
The safest solution is usually not to move the data at all. Keep the existing dataset and share path, create the new identity, add a precise ACL entry, test both protocols, and disable the old login only after verification. Ownership and access can change independently of where the ZFS data blocks live.
Do not add iSCSI to the same design. SMB and FTP expose files; iSCSI exposes a block device that a client formats and manages as a disk. It is a separate storage service with different authentication and corruption risks.
Identify the Installed TrueNAS Edition and Version
TrueNAS CORE and SCALE have changed their service screens over time. A setting described for one release may not exist under the same name in another. Record the exact version before following a menu path and use the matching branch of the TrueNAS Documentation Hub.
Also record the storage layout:
zfs list -o name,mountpoint,used,available
In the web interface, note:
- Pool and dataset containing the 4 TiB.
- Dataset mount path.
- SMB share path and Purpose preset.
- Dataset ACL type and current owner/group.
- Old user’s numeric UID and groups.
- Whether the user’s home is an ordinary directory or its own child dataset.
- Snapshots, quotas, encryption roots, and replication jobs.
Export the TrueNAS configuration database and take screenshots of the ACL and share settings before changes.
Keep Protocols in Their Correct Roles
| Protocol | Exposes | Authentication | Use in this design |
|---|---|---|---|
| SMB | Files and directories | TrueNAS/AD user plus filesystem ACL | Primary Windows share |
| FTP/FTPS | Files and directories | Local user plus filesystem permissions | Legacy transfer only when required |
| SFTP | Files and directories over SSH | SSH account/key plus filesystem permissions | Safer replacement for plaintext FTP |
| iSCSI | Raw block storage/LUN | Initiator controls plus optional CHAP | Separate zvol or extent only |
TrueNAS’s current iSCSI documentation describes targets, extents, portals, initiators, and CHAP—not ordinary local file users. A client mounting a LUN owns the filesystem inside it. Never simultaneously expose that filesystem as a normal SMB folder from TrueNAS.
Avoid One “All Services” Group
A group can simplify ACL management for a genuinely shared dataset, but it should not mean “every user can access every storage service.” Service access and file access are separate:
- SMB authentication decides who can open the share.
- Dataset ACL decides which files they can read or change.
- FTP/SFTP service policy decides who may log in.
- iSCSI target and initiator policy controls block access.
For private user areas, create one dataset or private subdirectory per user and grant only that user plus administrators. If a common project area is needed, create a separate shared group and dataset. This prevents group convenience from defeating privacy.
TrueNAS now documents SMB private dataset shares as an alternative to legacy home-share designs. Use the preset supported by the installed version for new deployments.
Reuse the Existing Dataset for the Replacement User
With 4 TiB already stored, changing the access identity is far cheaper and safer than relocating files.
- Take a recursive ZFS snapshot of the affected dataset from the TrueNAS UI.
- Create the replacement local user with a unique UID; do not reuse or change the old UID yet.
- Do not create a new 4 TiB destination dataset.
- Add the replacement user to the existing dataset ACL with the required read/write/execute and inheritance flags.
- Keep the old user entry temporarily so rollback remains simple.
- Test a small existing folder, a new file, rename, delete, and a large-file transfer over SMB.
- Test from a second Windows session that should be denied.
- Only after all tests pass, disable the old account’s login and remove its ACL entry when policy allows.
Use the TrueNAS ACL editor rather than recursive chmod or chown. A Windows-style NFSv4 ACL can contain inherited entries and metadata that mode-bit commands flatten or invalidate.
If the existing data is owned only by the old numeric UID and has no suitable ACL, add an explicit inheritable ACE for the new user or a narrowly scoped group. Apply ACL changes recursively only after estimating the metadata work and taking a snapshot; four TiB can contain millions of files even when data blocks do not move.
SMB and FTP Can Point to the Same Dataset—with Conditions
TrueNAS’s current multiprotocol share guidance says its Multi-Protocol SMB preset coordinates access not only with NFS but also with paths accessed by local processes, containers, or FTP. It also warns that simultaneous access to the same files can still cause conflicts or corruption.
For an existing dataset:
- Configure the SMB share for the existing path using the version-appropriate Multi-Protocol purpose/preset.
- Review the resulting dataset ACL rather than accepting it blindly.
- Configure the file-transfer account to land in that same dataset or an allowed subdirectory.
- Ensure new files created through either protocol inherit an ACL usable by the other.
- Do not edit the same file concurrently through SMB and FTP.
TrueNAS’s current FTP service documentation requires a local user and dataset/home-directory design and notes that multiple accounts cannot use the same dataset as their home directory. That is another reason not to model a shared area as every user’s identical home. Use a dedicated transfer account or an approved subdirectory/ACL design supported by the installed release.
Prefer SFTP when the client supports it. Plain FTP transmits credentials and data without encryption. If FTP is mandatory, restrict it to a trusted management network or use FTPS according to the current TrueNAS service options.
Windows Can Cache the Wrong SMB Identity
Windows normally uses one credential set per server name within a logon session. A test can appear to use the new account while an old SMB session remains cached.
List current connections:
net use
Disconnect only the verified TrueNAS mapping or server connection. Do not use a broad delete command on a workstation that has unrelated mapped drives. Then remove the matching stored credential in Credential Manager, reconnect by one consistent server name, and specify the new TrueNAS username.
Using both an IP address and a hostname can create confusing parallel sessions. Pick one canonical name for tests.
If a Move Is Truly Required
First determine whether source and destination are in the same ZFS dataset.
- Renaming a directory inside one dataset normally changes metadata and does not duplicate 4 TiB of file content.
- Moving files across dataset mount points is a copy-and-delete operation, even when both datasets belong to the same pool.
- Renaming a ZFS dataset can be metadata-only, but it changes the dataset name/mount relationship and can break shares, snapshots, replication, quotas, and encryption assumptions.
Do not run mv until the dataset boundary is proven. A nearly full pool is a poor place to discover that a “move” is actually copying. The no-move ACL approach is usually the better identity migration.
If a path rename inside one dataset is necessary, stop SMB and FTP access, take a snapshot, verify that the destination does not exist, perform the rename from the TrueNAS-supported shell, update share paths, and test before deleting or disabling any rollback configuration.
Verification Checklist
For the new user:
- Existing files open over SMB.
- A new file created over SMB is visible through the transfer protocol.
- A new upload is visible and writable over SMB.
- Renames and deletes match the intended policy.
- ACL inheritance is correct on a new nested folder.
- Snapshot browsing or previous versions still works.
For isolation:
- User A cannot list user B’s private path.
- User B cannot authenticate to services not assigned to them.
- Guest SMB access is disabled unless explicitly required.
- iSCSI portals and initiators are limited independently.
For recovery:
- The pre-change snapshot exists.
- The old account can be re-enabled during the transition.
- The configuration backup is stored outside the TrueNAS boot device.
- Pool free space and alerts remain healthy.
Conclusion
Changing a TrueNAS user does not require moving 4 TiB of data. Keep the existing dataset, snapshot it, grant the replacement identity through the ACL, and retire the old login after protocol and isolation tests.
SMB and FTP can expose the same files when the installed TrueNAS version’s multiprotocol settings and ACL inheritance are used carefully. iSCSI cannot be folded into the same folder model; it belongs on a separate zvol or extent with its own initiator policy. This separation preserves data, avoids an impossible copy, and makes each access decision auditable.
