MacOS and setgid / sticky bit (the later being ignored)

[kobuk]

I am having some issues with permissions: MacOS via SMB seems to ignore file system permissions (especially the sticky bit).

Does anyone of you have a hint how I could convince MacOS via Samba to obey the sticky bit?
And: are you aware of any good reason why setting "nt acl support = no" in the samba share options is a bad idea?

I am writing this here since it seems the only fix seems to be in the truenas/samba setup. In the terminal everything works as intended - so, the file system acls should be fine.

The starting conditions:
All my users are running MacOS 12.6 (no Windows users) and the server is running TrueNAS-SCALE-22.12.0.

I am trying to prevent user from deleting a specific folder in a SMB share where they otherwise can do pretty much anything. Multiple users can access the share. They should be able to create and delete their files/folders in the share - except this specific folder. Within this specific folder they again should be able to delete/create everything - also files of other users. What I set up so far works perfectly via ssh. But MacOS via finder ignores the sticky bit:

My strategy so far:
So far my strategy is to set the setgid and sticky bit of the parent folder "Transfer" (which is also a dataset and share at the same time):

Code:

exampleuser@truenas:/mnt/DataPool/Transfer$ getfacl .

# file: .
# owner: root
# group: builtin_users
# flags: -st
user::rwx
group::rwx
group:backup:r-x
group:builtin_administrators:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:backup:r-x
default:group:builtin_administrators:rwx
default:mask::rwx
default:other::---

The folder (located within the above mentioned parent folder) - which nobody should be able to delete:

Code:

exampleuser@truenas:/mnt/DataPool/Transfer$ getfacl dont_delete_me/

# file: dont_delete_me/
# owner: root
# group: builtin_users
# flags: -s-
user::rwx
group::rwx
group:backup:r-x
group:builtin_administrators:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:backup:r-x
default:group:builtin_administrators:rwx
default:mask::rwx
default:other::---

Example of a user:

Code:

exampleuser@truenas:/mnt/DataPool/Transfer$ id
uid=3000(exampleuser) gid=3000(exampleuser) groups=3000(exampleuser),545(builtin_users)

All other users are also member of the "builtin_users" group.

This works fine in the terminal via ssh: users cannot delete the "dont_delete_me" folder - the sticky bit makes sure of that since the folder is not owned by them. If a user creates another folder inside the "dont_delete_me" there is no sticky bit and other users therefore can delete those subfolders (because they are member of the "builtin_users" group). Perfect.

The issues
Now, when a user accesses this share via samba and the MacOS finder, the following, very different behavior can be observed:

1. The setgid flag gets ignored and files/folders get created with ownership exampleuser:exampleuser instead of exampleuser:builtin_users preventing other users to delete within the "dont_delete_me" folder.
   I could fix this by adding "nt acl support = no" to the Auxiliary Parameters of the respective share. Now MacOS obeys the setgid flag.
2. The sticky bit gets ignored: While users cannot rename the "dont_delete_me" folder, they can simply delete it! Apple, what are you doing?

Following my Samba config for the respective share:

Code:

exampleuser@truenas:/mnt/DataPool/Transfer$ sudo net conf list
[GLOBAL]
    disable spoolss = true
    syslog only = False
    winbind request timeout = 2
    create mask = 0775
    ntlm auth = False
    bind interfaces only = True
    logging = file
    unix charset = UTF-8
    restrict anonymous = 2
    netbios aliases = 
    fruit:nfs_aces = false
    netbios name = truenas
    dns proxy = false
    server multi channel support = False
    guest account = nobody
    max log size = 5120
    local master = True
    server string = TrueNAS Server
    fruit:zero_file_id = false
    load printers = false
    workgroup = WORKGROUP
    passdb backend = tdbsam:/var/run/samba-cache/passdb.tdb
    directory mask = 0775
    printcap name = /dev/null
    log level = 1 auth_json_audit:3@/var/log/samba4/auth_audit.log
    server min protocol = SMB2_02
    idmap config * : range = 90000001 - 100000000
    idmap config * : backend = tdb

[Transfer]
    vfs objects = fruit streams_xattr acl_xattr zfs_core io_uring
    ea support = False
    tn:purpose = NO_PRESET
    path = /mnt/DataPool/Transfer
    tn:path_suffix = 
    tn:home = False
    comment = Temporary files to be moved somewhere else. Files will get deleted after a while.
    read only = False
    browseable = True
    guest ok = False
    hosts allow = 
    hosts deny = 
    access based share enum = False
    posix locking = False
    kernel oplocks = False
    smbd max xattr size = 2097152
    fruit:metadata = stream
    fruit:resource = stream
    fruit:time machine = False
    fruit:time machine max size = 0
    tn:vuid = 
    nt acl support = no

Thank you very much for any feedback! This issue is causing me serious headaches.

 

[kobuk]

Just for the record let me describe my workaround so users cannot delete the dont_delete_me folder: I ended up with creating a sub dataset within the SMB shared original "Transfer" dataset. MacOS thinks it can delete it but if the user tries this obviously fails and therefore achieves the desired effect.

I my example I deleted the /mnt/DataPool/Transfer/dont_delete_me folder and instead created a "dont_delete_me" dataset in the "Transfer" dataset.