6

Both my server and my client are running macOS Monterey 12.4. I've shared folders on the server, enabled SMB sharing in the options and enabled the accounts for Windows sharing. On the client, I connect with smb://user@server. I get an error message saying that access to the account has been denied by the server.

In Console on the client I have this:

debug   00:57:01.961611+0200    NetAuthSysAgent AuthenticateWithURL: Authentication FAILED, user name <private> domain '<private>' gss client principal <private> - 9 gss server principal <private> - 3  for <private>
debug   00:57:01.961658+0200    NetAuthSysAgent SMB_OpenSession: - error = -5999!

And on the server:

error   00:59:40.065161+0200    smbd    smb2_dispatch_session_setup: session_setup_transact status: 0xc000006e

Any idea what I could try to get access?

Improve this question
3
  • Is your directory service ldap on another server or are you relying on the local directory services? Excellent updating - thank you!
    – bmike ♦
    May 18, 2022 at 16:07
  • @bmike I tried both, with and without Open Directory service.
    – Ortwin Gentz
    May 19, 2022 at 7:57
  • Oooo great find, this exactly answers a question I previously posted: apple.stackexchange.com/q/426769/8320
    – Alexander
    May 25, 2022 at 1:56

3 Answers 3

Reset to default
5

This Apple Technote provided the solution. The key is to add the SMB users to the SMB service access control list (SACL).

I had to run these commands for each user that needs to be authenticated via SMB:

Determine the user's GUID:

dscl /Search read /Users/<username> GeneratedUID

Add the user to the SMB service access control list (SACL):

sudo dscl /Local/Default append Groups/com.apple.access_smb GroupMembership <username>
sudo dscl /Local/Default append Groups/com.apple.access_smb GroupMembers <guid>

If you want to remove the SACL, use the following Terminal command:

sudo dscl /Local/Default delete /Groups/com.apple.access_smb

It's beyond me why this manual intervention is actually needed. A clear bug if you ask me. The Sharing settings pane should do this automatically.

Improve this answer
2
  • Maybe this is a silly question but... why is this even necessary? This manual step wasn't necessary before, and I don't know what changed since then to make it necessary.
    – Alexander
    May 25, 2022 at 1:58
  • Went there, tried that, none of it worked. Perhaps this manual intervention works for "APFS" and not exfat. I have an external RAID5 formatted as exfat and everything recommended by that "Apple Technote" fails. :(
    – Bruce
    Jun 22, 2022 at 18:56
1

Had the same issue — other solutions provided here didn't work for me. In my case the share is on an external drive. I noticed a log on the server:

error   14:57:41.211700-0700    kernel  System Policy: smbd(23190) deny(1) file-read-data /Volumes/plethora

I had to go to System Preferences > Security & Privacy > Privacy > Full Disk Access and add /usr/sbin/smbd to the allowed apps.

Improve this answer
1

I want to chime in here, in case this can help someone else! I tried the solution above from @OrtwinGentz, but it didn't work for me; HOWEVER, it did lead me to a similar solution that did work for me. My problem manifested a little differently, but I think it had the same underlying cause (whatever that may be).

My config: I have a 2014 Mac Mini server with 2 raid shares that we use on various machines within our company network. We have Mac clients on several different OS versions, Win clients on several OS versions and a Linux client running Ubuntu 20.04 on the network. We use the AzureAD that comes with O365 for authentication of the Win machines and also have an Active Directory server in Azure that is synced with the O365 AD and also serves as our DNS master, which is used by the Macs and some other devices. The Linux machine is listed in the AD system and uses the Azure DNS server, but is not joined to the domain for auth purposes - it uses local auth only.

Prior to the problem, most network machines mounted the drive using the qualified machine name (e.g., <computer>.ad.<domain>.com). Two exceptions were one win11 machine and the Linux machine, both of which could only mount using the ip addr.

The Problem: We upgraded the Mac Mini to Monterey (12.5) and that's when the trouble started. Most machines were able to mount the shares, except for the one Win11 and Linux machines. I tried for 2 days to fix, but couldn't find a solution. I had run across this SE topic, but the dscl commands failed, so I moved on. I circled back to it today and decided to look harder at why they didn't work.

The Solution: I used the Mac Directory Utility to look into the Local Groups directory and saw that there indeed was NOT a SMB entry with RecordName = com.apple.access_smb, but rather a bunch of (8-9) entries for each shared resource, which had in the RecordName com.apple.sharepoint.group.NN (NN=2-digit number). On a whim I chose one of these 'raid' groups and substituted its RecordName in the dscl commands from the solution above.

sudo dscl /Local/Default append Groups/com.apple.sharepoint.group.23 GroupMembership <username>
sudo dscl /Local/Default append Groups/com.apple.sharepoint.group.23 GroupMembers <guid>

BAM!! The Linux system mounted right up! Then the Win11 system too! I also found that I didn't need to add users to every share, both raids mounted fine. I then added the other users that might use the Linux or Win11 systems and poured myself a cold one... Cheers.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .