Setting up Truenas Scale including permisions and shares for SMB
Setting up permissions and shares for SMB.
Diving into the way I will be setting up a production truenas scale server. What are the best practices and what to avoid. The instructions here are for once you have followed all the built in setups, and created a pool. This inforamtion will walk through; Users, Groups, Datasets and Shares.
Today I'm setting up a QNAP TS-h1677AXU-RP-R7-32G 16-Bay Diskless NAS Ryzen 7 7000 CPU 32GB RAM.
It has 2 pools, 1 for Hard drives and 1 for solid state drives.
hddpool has 2 vdevs with 8 drives in each using RAIDZ2. TOTAL 165.
ssdpool has 1 striped vdev with 2 ssd drives. TOTAL 8TB.
HDDpool will be used for important information, the ssdpool is used for less critical stuff that we want fast access to.
SMB v NFS
SMB shares seem to be the best way to share stuff in a mixed OS environment, due to their user based logins and great but potentially overwelming ACL permissions.
NFS shares are fast, and on linux easy to mount on other devices. However the issue arrises around permissions, NFS uses the userID, which on most machines will be 1000 by default. this would require you to change the UID of every user accessing the nas and setup an account in Truenas that correlates 1-1. If user 2000 where to change their UID to 1000 they would then have the permissions of 1000 on the nas. This is undersireable behaviour.
SSHFS is another filesystem option, and is very useful for secure remote access as the data will be encrypted by default, but has performance penalties.
SMB with supplimental use of SSHFS (if needed) is my reccomended setup.
Groups
The best practice is not to expose every user to have access to a pool but rather individual 'datasets', these datasets could be; 'IT', 'Accounts', 'Management' etc. We would create a group per dataset (you can even nest datasets if you want). Users are then assigned to only the groups they need. for example the IT manager might have the IT and Management groups, but not the Accounts group.
Lets make a group; goto credentials > groups, give it a name and make sure you check the option for SMB shares.
Users
First we make a test user in credentials > users. give them a username and password and make sure to enable the SMB share checkbox. In the additional groups section add them to the group you created above.
Datasets
Making a dataset, we are going to make the test dataset on the hddpool. give it a name and then select the SMB preset and name the share the same as your dataset. click advanced options, you will likely want LZ4 compression, deduplication off, access time off, ACL should be SMB/NFSv4 and the ACL mode should be 'restrictive'. These are generic best practices, the level of your hardware could change these. Record Size is something you may want to change based on your usecase but 128kib is a good starting point.
Applying Permissions
Once the share is created, the next crucial step is to configure the Filesystem ACL to control user access.
This example assumes the creation of a /mnt/hddpool/shares/test dataset and two groups: test-manager (read/write access) and test-user (read-only access).
Navigate to the ACL Editor:
-
Go to Datasets.
- Select the /mnt/hddpool/shares/test dataset.
- In the Permissions widget on the right, click Edit.
-
Set Ownership:
- In the Edit ACL screen, the Owner and Owner Group should be set to an administrative account. For example, set Owner to your main admin user (e.g., admin) and Owner Group to builtin_administrators or another admin group.
- Click Apply Owner and Apply Group.
-
Apply a Baseline Preset (Optional but Recommended):`
- Click Use Preset and select NFS4_RESTRICTED. This establishes a secure baseline where the owner has full control, the group has modify rights, and others have no access.
-
Assign Manager Access (Read/Write):
- Click Add Item.
- In the new Access Control Entry (ACE) section, set Who to Group.
- In the Group field that appears, select the project-managers group.
- Set Permissions to Modify. This provides read, write, and delete capabilities.
- Under Flags, ensure FILE_INHERIT and DIRECTORY_INHERIT are selected so that new files and folders created by managers inherit these permissions.
-
Assign Intern Access (Read-Only):
- Click **Add Item` again.
- Set Who to Group and select the interns group.
- Set Permissions to Read. This allows viewing files and listing directories but prevents modification.
- Under Flags, ensure inheritance is also selected for this entry.
-
Apply Recursively (If Necessary):
- If the dataset already contains files and folders, check the Apply permissions recursively box at the bottom of the ACL editor. This will strip the old permissions and apply this new ACL to all existing content within the dataset.
- Use with caution: This is a destructive operation for existing permissions, so it should be used deliberately when establishing or resetting the security policy for a dataset.
-
Save the ACL:
- Click Save Access Control List.
SMB service
If you madee the dataset with the preset this would have been turned on for you but you should check, goto System Settings > Services in the list you will see SMB. Use the toggle to turn it on at boot and the toggle to turn it on right now.
If you are following this guide you can turn off NFS. And make sure that S.M.A.R.T is running and enabled.
Connecting clients
In your file explorer of choice find the network share section and add a conneciton.
-
Windows: Open File Explorer. In the address bar, type
\\<truenas-ip-or-hostname>\<share-name>(e.g.,\\192.168.1.50\testor\\truenas\projects) and press Enter. A credential prompt will appear; enter the username and password of an authorized user. -
macOS: Open Finder. From the menu bar, select Go > Connect to Server. In the dialog box, enter
smb://<truenas-ip-or-hostname>/<share-name>(e.g.,smb://192.168.1.50/test) and click Connect. Authenticate when prompted. -
Linux (GUI): Most modern desktop environments (like GNOME or KDE) have a file manager with a "Connect to Server" feature. Use the
smb://<Ip-or-hostname>\<share-name>address format as with macOS. -
Linux (CLI): For command-line access or mounting via /etc/fstab, the cifs-utils package is required. The share can be mounted with a command like:
sudo mount -t cifs -o username=<user> //192.168.1.50/projects /mnt/mymountpoint. This works for mounting as root as a read only fs for your user. To properly mount for actualy use you will need to do it via fstab and provide the user credentials for mounting.*
Domain: the login prompt may as for a "domain", if the default value does not work, you can find your domain at Service > SMB service > Click the pencil > NetBIOS Name. Enter this value as the Domain.
SMB Hardening.
For any remote use, a VPN like Tailscale, wiregaurd, openvpn, or a specific flavour like Sophoss Connect. Should be used for mounting the SMB drive. Performance will be limited by the internet connection, but this is the most secure way to access the server.
Ensure users are using strong passwords and in the TrueNAS user settings disable non SMB access (ssh or Truenas login). This minimises the attack vector.
SMB Performance
SMB Tuning for Small File Performance.
Currently you cannot edit the SMB custom parameters in truenas UI, so we have to add them using this method below.
These settings reduce metadata overhead for each file operation, improving performance for workloads with many small files.
Find Share ID:
midclt call sharing.smb.query
Apply Parameters: Use the ID from the previous command.
midclt call sharing.smb.update <id> '{"auxsmbconf": "ea support = no\nstore dos attributes = no\nmap archive = no"}'
-
ea support = no: Disables support for general Extended Attributes.
-
store dos attributes = no: Disables storing legacy DOS attributes (Hidden, System, etc.) in extended attributes.
-
map archive = no: Prevents Samba from mapping the Windows "Archive" bit to the Unix execute permission bit, which adds unnecessary overhead.