We're running a Mac OS 10.8.3 server using the File Sharing feature. We have both AFP and SMB sharing enabled.

When we change a user's permissions, their permissions are set properly when accessing the server via AFP, but when using SMB, their permissions are incorrect. As an example, we removed a user from a group, and while on AFP they are properly blocked, they can still access their old folders using SMB. I have confirmed it is not a caching issue, as new content within the blocked folders is also visible to them.

This is clearly a major security issue, but I have no idea how to fix it. I've tried enabling ACLs on SMB, but to no avail.

Any help would be appreciated!


  • Adding a user to a group DOES update permissions on the SMB share, and immediately. However, REMOVING the user from a group does NOT remove their permissions on SMB. In other words, a user retains any groups they've ever been in for the SMB share.
  • If I change the permissions on a folder, everything updates immediately.
  • Using SSH, I can confirm that the user's permissions are indeed updated properly in UNIX; if I remove them from the group, they no longer have access to those folders via SSH (or AFP).

So basically, the problem is removing a user from a group - it removes their permissions on the AFP share, but to SMB, it thinks the user is still in the group that they were removed from.

  • What client OS is in use and what authentication method is used? Are these Windows clients authenticating against AD? – joeqwerty Mar 26 '13 at 20:09
  • Active Directory isn't used, just basic user account authorization. The client is either Mac OS 10.8.3 or Windows 8 via SMB. (Mac OS X connects fine on both, but permissions over AFP/SMB are different). Both Windows and Mac show the same permissions when using SMB. – Justin Mrkva Mar 26 '13 at 20:57
  • I'll work on reproducing this, in the mean time - what ACL are yo setting on the server side for a folder and how is a Mac client showing you the settings once the SMB mount is completed? – bmike Mar 27 '13 at 17:43
  • On one of the folders, I have the permissions as follows via the Server.app interface. Group1:read/write, Spotlight:custom, Owner:read/write, staff:none, Others:none. Permissions on the enclosing folder are: Group1:read Group2:read/write, Owner:read/write, staff:none, Others:none. The user I'm connecting with is in Group2 but not in Group1. In the meantime, it looks like permissions for the test user did in fact update. I'm definitely interested in if you're able to reproduce it though. I'll be doing some testing on my end as well to see if it's reproducible, and if so, what the delay time is. – Justin Mrkva Mar 28 '13 at 16:31
  • Sorry, my bad. The permissions did NOT update, I was going off of bad information. They're still exactly like they were, and not correct. – Justin Mrkva Mar 28 '13 at 16:57

It looks to me that this is a caching issue, but caching of group memberships not files, and it's not just the SMB service. If I add someone to a group, then make an SMB or AFP connection to the server, or a Terminal session, or even log directly into the desktop on the server; then remove them from the group, the active session(s) seem to retain that group membership for as long as I tested (at least a few minutes).

The effects of this can be a bit strange. The retained group membership seemed to be linked to when a process was started; for example, I logged in to the desktop as a particular user, revoked their group membership, then opened Terminal -- at that point, Finder could still access files based on the former group, but the Terminal session couldn't.

New sessions might get the group membership, but only if they started within a few seconds of the group membership being revoked. So I think there are actually multiple layers of membership caching...

| improve this answer | |
  • Sounds plausible. However, we've rebooted the server since revoking the permissions, to no effect. Also, I'm curious if you have any insights into how to control the caching. I can confirm that AFP/SSH/login permissions are revoked properly, and AFP at least (I didn't test local login or SSH on this one) revokes permissions immediately, even during an active connection. – Justin Mrkva Mar 29 '13 at 20:46
  • Issue is obsolete, so I'm accepting this answer for the heck of it. :) – Justin Mrkva Jan 22 '14 at 16:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.