I am new to TrueNAS and SMB and currently setting up a new storage system. I have an encrypted dataset, under which I created a share with several subdirectories.
What I need is the following:
The owner of the directories and files should be able to change and delete them.
The group Members should be able to work with the files (read, edit, and create files in the directory) but must not be able to delete them.
The ACL configuration works perfectly for Windows and Linux, but it does not work correctly on macOS.
This is the ACL setup I am using:
for dir in test1 test2 test3; do
echo "Setting ACL on $dir..."
printf '%s\n' \
"owner@:rwxpDdaARWcCos:fd-----:allow" \
"group:8004:rwxpDdaARWcCos:fd-----:allow" \
"group:8005:----Dd--------:fd-----:deny" \
"group:8005:rwxp--aARWc--s:fd-----:allow" \
"group:8000:r-----a-R-c--s:-------:allow" \
| nfs4xdr_setfacl -R -S - /mnt/storage/dbvis-storage/data/$dir
done
And this is the relevant Samba configuration:
dos filemode = No
map acl inherit = No
nt acl support = Yes
store dos attributes = Yes
vfs objects =
vfs objects = catia fruit streams_xattr shadow_copy_zfs ixnas zfs_core io_uring
vfs objects = fruit streams_xattr shadow_copy_zfs ixnas zfs_core io_uring
Could someone help me understand why this works on Windows and Linux but not on macOS? Thank you in Advance
Hello Johnny, thank you for quick answer
hier the informations.
For me is very confusing, that in windows all works and Mac could not create files but it can delete my files.
root@truenas:/mnt/storage/dbvis-storage/data/test1# zfs get aclmode,aclinherit storage/dbvis-storage
NAME PROPERTY VALUE SOURCE
storage/dbvis-storage aclmode passthrough local
storage/dbvis-storage aclinherit passthrough local
How is it the choice of the client to follow or ignore a filesystem ACL? The access from smbd should be performed with the local user ID of the authenticated user and then ACLs should locally kick in - hard.
I’m not questioning your statement, but it really puzzles me. I always thought my above summary was how this worked.
In which way is an access by smbd different from one by the respective user logged in locally?
It kicks in hard. There’s not really a mechanism for an authenticated client to bypass it. Depending on access rights granted though, the client can rewrite the ACL to do what it wants. Like above ACL grants owner of file permissions to rewrite the ACL. That said completely removing delete also removes ability to rename a file. If client has workflow whereby it initially creates a temporary file and then renames it to final name, this will break it.
Yeah I think whats happening here is the Mac client is doing a rename or a replace instead of a delete so the ACL allows it as it’s not actually a delete.
Regardless, the “set permissions so that people can write but not delete” has always struck me as pretty problematic. It still allows truncating files to zero bytes (effectively deleting it) and a variety of ways to break the content, as well as violating client expectations about the FS will behave. Usually it’s just better to have a sensible snapshot policy.
Hello everyone
Thank you very much for your contributions.
I’m starting to get a bit desperate with this issue
At the moment my task is to implement this policy. I will try to explain the situation clearly to my boss for further discussion, although I’m not very optimistic that he will be willing to give up on this requirement.
From my discussions with AI tools, one explanation seems to be that macOS uses a sandbox model, which may affect how permissions are handled. This could be the reason why the permissions are not working as expected.
Does anyone have another idea how this problem could be solved, other than avoiding the use of Macs? :-))
In my org we have two types of permissions modify or read-only.
As @awalkerix has rightly highlighted having a permission group that allows a user to essentially destroy a file by for example deleting its contents but not the actual file itself seems to miss the point. You either trust people to create, modify and delete or you don’t. There is always WORM that can be enabled at the share level but this may not be suitable for your situation.
Also as mentioned having a sound recovery and backup strategy in the event of malicious or accidental deletion is probably the best option overall.
Not sure what this is supposed to mean… Or how AI is going to help in general.
The most obvious explanation is that the macOS Finder does not plainly deletes files: Files are moved to the Trash folder, and deleted later; this counts as “rename”.
Good luck explaining to your (pointy-haired?) boss that the designed policy does not make technical sense…
