Setting ACLs when creating files from Windows

Corinna Vinschen corinna at
Thu Aug 7 13:32:42 GMT 2008

On Aug  7 07:48, simo wrote:
> On Thu, 2008-08-07 at 12:12 +0200, Corinna Vinschen wrote:
> > I am having a Windows DC, but that's not really the point.  What I'm
> > looking for is something which should work also for users which just
> > have a Windows client OS and a Linux machine sitting under their desk,
> > whihc no domain setup at all.  The idea was that there's an automatic
> > mapping from the user and primary group SIDs in the Windows user token
> > of the authenticating user to a uid/gid pair on the Samba machine, using
> > the information in the usermap file.  However, since Volker mentioned
> > that there are no SIDs transferred from the Windows client machine to
> > the server at authentication time, there's not much chance that this
> > would work as I had hoped for.
> If there is no domain setup, the SID you use on the windows client has
> no meaning for the samba server. The Domain part will just be alien.
> Only a domain setup where all the players are member of the same domain
> (or trusted set of domains) can use directly SIDs, as in the case both
> parties have a way to understand what they mean.
> To be honest, windows machines can store in the file system just any SID
> handled to them, but they will never do any mapping server side.
> So if you take 2 windows client and try to set the SID of user Foo on
> client 1 on client 2, user Foo of client 2 will not actually be able to
> access the resource, as the SID will not match.
> In general it's best if you avoid assuming what SID belong to whom on
> network communications.

Well, in theory I don't care if it's a network FS or a local FS.
Cygwin's open() code simply tries to create files with a SD which
contains the current user, its primary group and an Everyone ACE,
regardless of the underlying FS.  This works fine on local and remote
Windows filesystems, just not on Samba which needs the described
workaround, and on NFS, which uses an entirely different mechanism, the
extended attributes approach.  It's not exactly Samba's fault, it's just
annoying that so many different code paths are required to get the same
result on different filesystems.  I had hoped for a simpler approach.


More information about the samba-technical mailing list