I’m trying to create a home dataset that will hold each user’s home directory, and I would like to utilise NFS4 ACLs as the clients are Linux, Windows, macOS, Android and iOS clients, therefore I would like to use an ACL type that has multi-protocol support.
I’d like to set the NFS4 ACLs so that each user has access to their respective directories. In addition, I would like the administrator group to have full control across all users and any new users added (inheritance ACE).
I used the following commands which should be self-explanatory
# Set ownership of the root home dataset directory
chown truenas_admin:builtin_administrators /mnt/pool0/home_dataset
# Clear existing ACLs on home dataset
setfacl -b /mnt/pool0/home_dataset
# Set ACL on the home dataset directory for administative access and inheritance
nfs4xdr_setfacl -R -s group:builtin_administrators:rwxpDdaARWcCos:fd:allow /mnt/pool0/home_dataset
# Restore ownership on each home directory to its respective user
for dir in /mnt/pool0/home_dataset/*; do
user=$(basename "$dir")
echo "Restoring ownership on directory '$dir' for user '$user'"
chown -R "$user:$user" "$dir"
done
However, upon creating the user foo in the TrueNAS web-GUI and enabling the option Create Home Directory as shown below, I then logged into the server via SSH to check permissions I could see the ownership was correct but the builtin_administrators group wasn’t inherited.
root@FS-Home:/# stat /mnt/pool0/home_dataset/foo/
File: /mnt/pool0/home_dataset/foo/
Size: 5 Blocks: 1 IO Block: 131072 directory
Device: 0,60 Inode: 33193 Links: 2
Access: (0700/drwx------) Uid: ( 3001/ foo) Gid: ( 3001/ foo)
Access: 2025-07-08 20:07:21.316097170 +0100
Modify: 2025-07-08 20:07:21.848094979 +0100
Change: 2025-07-08 20:07:21.848094979 +0100
Birth: 2025-07-08 20:07:21.316097170 +0100
root@FS-Home:/# nfs4xdr_getfacl /mnt/pool0/home_dataset/foo/
# File: /mnt/pool0/home_dataset/foo/
# owner: 3001
# group: 3001
# mode: 0o40700
# trivial_acl: true
# ACL flags: none
owner@:rwxpD-aARWcCos:-------:allow
group@:------a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow
I don’t have hundreds of users so I could theoretically re-run the command below
to recursively apply the builtin_administrators group ACL to all users under the /mnt/pool0/home_dataset
nfs4xdr_setfacl -R -s group:builtin_administrators:rwxpDdaARWcCos:fd:allow /mnt/pool0/home_dataset
Is the only the way to achieve this, or is there some way of being able to set the ACLs/permissions once and once only?
Hi and welcome to the forums.
This may help Understanding Home Directories - #18 by Johnny_Fartpants
Personally I’d keep it simple and just use SMB as all your clients will work fine that way and it will be less complex and easier to manage.
I think this is the issue: # trivial_acl: true. I am guessing that when Truenas made the home directory it ran chmod and nuked the ACL. You can prove ACL inheritance is working as you expect via the command line by making a subdirectory and some files by hand under home_dataset, and see that they get the right permissions.
If this is correct, your present best option for multi-protocol access is to make the home directory yourself and not allow TrueNAS to change the permissions. You can also set aclmode=restricted to prevent setting trivial ACL if you are only sharing via SMB. Setting aclmode=restricted is presently incompatible with Mac NFS clients, which treat fchmod() failures as a hard failure – I have filed a bug with Apple.
Can you also please consider voting for: Implement zfs aclimplicit to control granting implicit privileges to change file ownership and ACL as without this there is no way for you to prevent users from changing ownerships or ACLs. If you also share files via NFSv4 this can happen accidentally when a client runs mv or cp -p. In particular for shares via NFSv4, you will also find that by default all files are executable which is probably not intended. You can set zfs aclinherit=passthrough-x to prevent this, or set 2 ACL: one for directory inheritance which include executable bit, and one for file inheritance that does not.
Also if I understand the intent of your ACL, it will not work as expected. If you set this at the top level:
owner@:rwxpD-aARWcCos:-------:allow
group@:------a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow
Assuming home_dataset is owned by root, users will not be able to chdir into their home directory because they don’t have traverse privilege (execute) on home_dataset. Instead at the top level set an ACL like this:
group:builtin_administrators:rwxpDdaARWcCos:fd-----:allow
owner@:rwxpDdaARWc--s:fd-----:allow
group@ -- to whatever you need, I used this with per-user groups:rwxpDdaARWc--s:fd-----:allow
everyone@:--x---a-R-c---:-------:allow
In the GUI this is set via:
- group:builtin_administrators:full control, inherit for files & directories
- owner@, group@: modify, inherit for files & directories
- everyone@: traverse, no inheritance
You could also give everyone@ read permission with no inheritance, which would let users see all the other home directories (but not access them).
It would also be normal for each user to have a dataset. This allows you to do things like per-user restores and users can access their own snapshots to self-restore. If you do this:
Last one… For access over NFS, files will be created with the permissions of the user’s umask and for now (until Mac clients do not treat chmod failures as hard failures) there is not much you can do about this. If you are sharing files via NFS you will need to work out the umask that makes sense for your environment and then set on all the clients.
If you are sharing more than just home directories via NFS, you might consider 007 which gives write access to owner and group, and no access to everyone. This is appropriate for group file shares, and works for homes as well with per-user groups, while not causing them too much trouble on their own devices.
Once Macs do not fail on fchmod you will be able to use zfs aclmode=restricted and ACLs to force permissions on new files independent of the user’s umask. This is not an issue with SMB where the server sets the file/directory mode, not the client.
