proposed new Unix QFS Info level

Steve French smfrench at
Tue Feb 6 22:48:06 GMT 2007

I agree that the SID(s) need not correspond with gids. There are likely to
servers which have difficulties with such mappings and even construct
from two distinct sources.

To do gid and uid mappings to/from SIDS e.g. to aid in ACL management
is probably better done via Volker's UnixInfo pipe.

On 2/6/07, James Peach <jorgar at> wrote:
> On 06/02/07, Conrad Minshall <conrad at> wrote:
> > For this interface you might want to specify that the number of SIDs
> > must be either zero or equal to the number of supplementary gids.
> > Then again, imagine a server for some reason is only able to determine
> > gid=>SID mappings for some but not all of the gids, in which case we
> > should define a structure which preserves the gid/SID correspondence.
> I'd prefer not to nail down the relationships between the SIDs and the
> GIDs in this case. For example, on Mac OS X, it's very hard to
> guarantee that the GID list is complete - the kernel only knows a
> small number of the group memberships at any one time. Since the group
> memberships can (potentially) change at any time, this information is
> best regarded as a hint and used for display purposes (ie. not for
> access control).
> Additionally, it is possible for a server to not map any of the GIDs.
> For example, there may be a server that provides *only* Unix
> semantics. In this case, the GID list oule be populated and the SID
> list would not be. I don't know of any such servers, but there was a
> desire to make this possible :)
> The main rationale for this extension is for Unix clients to be able
> to sensibly display whether files are "owned by me" or "owned by
> someone else, as per "ls -l". A secondary rationale is to be able to
> determine whether a client has been mapped or forced to guest on a
> per-share basis. This can happen with some Samba configurations.
> --
> James Peach | jorgar at



More information about the samba-technical mailing list