macOS SMB ACL Permission

Hey all, having an issue with ACL’s on macOS. Running Dragonfish-24.04.2, the system is domain joined, smb share has an ACL, using the default NFS4_OPEN preset.

If I set the acl to drwxrwxrwx I get that on windows and linux. On the Mac side I’ll only get drwx------+

Tried Enabling and Disabling Apple SMB2/3 Protocol Extensions but that seems to have no effect.

Thanks in advance.

Are you managing permissions from the UI? If so can you post some screenshots of your current setup?

Sure, not doing anything in the command line. Here’s the screenshot of the ACL.

We don’t enable the NFS aces that MacOS uses to try to suss out posix mode (because it would be inaccurate). The + in MacOS indicates ACL is present and POSIX mode is not to be trusted.

1 Like

Apologies, I just looked up the + and @ character usage for permissions on macOS.

If I add the -e flag to ls I can see all the ACL’s correctly. So my shares do have the ACL equivalent of 777 already.

TIL

ls -la
-rwx------@  1 user  DOM\Domain Users    529  1 Dec  2023 notes.txt
ls -le

-rwx------@ 1 user  DOM\Domain Users    529  1 Dec  2023 notes.txt
 0: user:files inherited allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown
 1: group:DOM\Domain Users inherited allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown
 2: group:everyone inherited allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown

Right. This is the same as if you had mounted a Windows server share. Displaying POSIX mode is a convenience feature, but it’s not terribly helpful since ACLs typically can’t be fully represented as a POSIX mode without loss of information.

1 Like

Sorry to resuscitate an old thread, but are you saying that ls -le on a mounted SMB filesystem in macOS shows you permissions? Is there some trick to this? I’m not seeing any permissions at all. macOS just (falsely) shows me my local account and group as the “owner” even though NFSv4 permissions are configured on the TrueNAS side.

This is along the lines of what I’m seeing: Permissions seen as "rwx------" from Mac despite ACLs having Full Access for group | TrueNAS Community

@awalkerix, any idea how to show actual NFSv4 permissions on an SMB share in macOS via ls -le? Is having a “domain joined” system related to this? I’m just connecting to my dataset using Cmd-K in Finder. Or… is this maybe something CE can’t do?

That’s a MacOS specific implementation question and how their SMB client decides to present SMB ACLs to clients. It’s way outside of scope of what is the TrueNAS server’s responsibility.

FWIW an SMB ACL contains a list of SIDs (basically UUIDs). The way that a client in theory would handle this and present a usable ACL interface would be:

  1. get ACL
  2. resolve the SIDs in the ACL to UIDs / GIDs on the Mac.

(2) is a problem if there is no mapping of the SIDs to UIDs / GIDs. This is obviously the case if the accounts are not shared between the Mac and TrueNAS (e.g. AD).

1 Like

Are the systems connected to a directory server?

If you want unified NFSv4 / SMB permissions then you need truenas and the workstation “joined” to an AD / ldap / freeipa server, otherwise they are managed separately in truenas.

My original post was dealing with domain joined systems.

If the share has “extended” ACL’s macOS will tell you when you ls -la a directory. You will see ------+ (files) or ------@ (folders) to let you know there are extended ACL’s.

drwx------+ 1 
-rwx------@ 1 

If you run ls -le you will see a long list of all the extended permissions available like this.

 0: user:files inherited allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown
 1: group:SITE\Domain Users inherited allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown
 2: group:everyone inherited allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown
1 Like

Thank you! I guess if there’s no directory server, macOS just spits out fake information. The UID/GID owners listed in macOS don’t even match the real numbers in TrueNAS, and there are no + or @ characters.

Curiously, Windows does something to make this work. If you go to the “Security” tab for an SMB share with NFSv4 ACLs, it first shows the raw SIDs, then spins a bit, then shows the actual names from the TrueNAS server. (None of them map to local accounts on my client machine.)

Right. It (Windows) connects to the hidden IPC$ share on the TrueNAS SMB server and basically performs RPC operations to resolve SIDs to names.

1 Like