Having issues with group memberships on mobile accounts?
Read on for one method of solving this.If you’re running with Mobile User accounts in your area, you may have noticed that every so often a Mobile User is unable to access a folder on an AFP share that they should have access to.
Basically the bug is that under certain circumstances only the primary group membership is cached, so if you have an area where the user is being granted permission via a non-primary group membership, the Finder thinks that you don’t have access. You’ll notice that if you connect to the same share via SMB or with the command line, the user has the correct access privileges.
Logging out and back in usually resolves the issue if the machine is connected to a wired network, but if your users are on a wireless connection, it often doesn’t.
My fix for this was to have a LoginHook that trashed the local MCX cache. So far this hasn’t had any negative side effects and has resolved this issue for my staff, but as always, YMMV and you should test this with your setup before deploying…
The LoginHook shell script looks like:
<code> #!/bin/sh /usr/bin/niutil -destroy . /config/mcx_cache </code>
Save this somewhere, I keep mine at:
/Library/LoginHooks/loginhook.sh
Make it executable, and then execute:
<code> sudo defaults write com.apple.loginwindow LoginHook /Library/LoginHooks/loginhook.sh </code>
(if you put the script somewhere else, change the path in the above command to reflect this)
From now on, when a user logs in, the script runs, destroying the local cache, so that it gets forced to be refreshed with the correct group memberships.
by 
This addresses one part of this problem, however…there may be a bit more
foolproof way.
The assumption here is at login time that you are on network and capable of
reaching the Directory Service where the MCX settings live. Of course, the
possible problem is you log in off-network where you can’t refresh the cache,
then attempt to connect to a share later.
This issue is, in reality, due to AFP permissions mapping as detailed in this
article:
http://docs.info.apple.com/article.html?artnum=107485
One alternative way to deal with this is to disable permissions mapping at the
server-side:
sudo serveradmin settings afp:noNetworkUsers = yes
which should do the trick.
Are you sure this will fix it?
I run into this situation exactly where Apple say that privilege mapping
doesn’t come into play, ie:
Privilege mapping is not used when:
The client and server share a common directory service such as Open
Directory, LDAP or NetInfo, and
The same account is used to log in to both the client and the server.
I’ll give that a go though, but I really don’t see how that is this issue. I see the
privileges correctly in a shell, it’s only the Finder that borks out.