Clearly, there is some cacheing going on, but I don't know where, why, or when.

Yes there is some "cacheing" going on, and this is probably what's causing your confusion. When a Windows client first establishes a CIFS session to the filer, either by mapping a network drive to a filer share or by accessing our file system using a UNC pathname, the Windows user is normally mapped to a valid UNIX identity so that the UNIX permissions in the file system can be enforced on that user. This is done by looking up the Windows username in the filer's /etc/passwd file (or the equivalent passwd.byname NIS map) and associating the users UNIX UID, primary GID and secondary GIDs with the established CIFS session (the secondary GIDs, if any, come from an /etc/group lookup, just like on UNIX). This mapping only occurs at session establishment time. If you subsequently add the user to another group by editing the /etc/group file, or change their UID or primary GID by editing the /etc/passwd file, the new values and/or group memberships will not be associated with the Windows user until they disconnect their session from the filer and then reconnect.

Forcing a Windows client to disconnect a CIFS session from a server is actually something of an art form. The CIFS redirector on Windows manages sessions largely independently of direct user actions, and this may also be causing some confusion. For example, a:

NET USE Q: \FILER\SHARE

will establish a CIFS session to the filer (unless there is one established already), but a:

NET USE Q: /D

will not disconnect the session. It will disconnect the network drive from the CIFS session (you won't have a Q: anymore), but the CIFS session itself will normally remain established, even if you have no other drives mapped to the filer. Only if you don't try and access the filer via *any* method (UNC or mapped drive) for a period of time (10 minutes is the default, but it can be changed in the registry) will the CIFS redirector quietly disconnect the session from the filer. This is just how Windows networking works, whether you're dealing with a filer or a Windows NT server.

So, if you mess with a Windows user's group memberships by editing the passwd and group databases, the easiest way to make *certain* that a new mapping is done immediately is to force a disconnect from the filer side using the "cifs terminate <workstation-name>" console command. I'm fairly certain that logging the user out of the Windows client and then logging them back in again will force a client side disconnect, but I haven't watched that one with my own eyes and I don't want to mislead you. The Windows redirector's session management policies can be a little esoteric. :-) Whatever you do, you can use the "cifs sessions" command to make sure that the client's session has gone before you try accessing the filer again from said client after making the changes.

As a final note, this mapping-Windows-users-to-equivalent-UNIX-users stuff is actually unnecessary if you are using the filer in a Windows-only context. If you enable NTFS security within our file system, Windows users do not have to be associated with unique UIDs and GIDs etc... in order for security to be enforced. In other words, Windows-centric folk should not be "scared" by any of the above. If you don't care about UNIX, none of this is necessary or directly applicable. If you just have a mass of humble Windows users, we don't "force" you to mess with passwd files, group files, UIDs, GIDs, UNIX perms etc, etc... to administer these users. It can all be done using regular domain accounts and NTFS permissions, all managed and administered from the standard User Manager for Domains and Server Manager NT tools, as well as the Explorer UI (file properties -> security -> permissions etc...).

Keith