This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New Cygwin 1.7.0-18 in release-2


On Jul 18 10:09, Corinna Vinschen wrote:
> On Jul 18 09:54, Corinna Vinschen wrote:
> > On Jul 18 09:34, Corinna Vinschen wrote:
> > > On Jul 17 18:18, Eric Blake wrote:
> > > > Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading
> > > > to the new cygwin1.dll today, I'm now suffering from an inability to
> > > > modify files on a shared drive on my work machine.  I can create empty
> > > > files and remove existing files just fine, but get access denied on any
> > > > attempt to change contents.  The -1 for owner and group looks fishy as 
> > > > well.
> > > 
> > > Drive U is apparently a Samba drive.  Is that in a Windows domain? 
> > > If not, try the noacl mount option.  It's equivalent to what was
> > > CYGWIN=nosmbntsec before.
> > 
> > Hmm, I can reproduce it and now that I see it myself I can see how
> > this is a problem with cygdrive mounts.
> > 
> > I assume the best way to handle this would be to set Samba drives to
> > noacl by default, right?
> 
> OTOH, I can't choose different mount options for different per cygdrive
> mounted drives.  All cydrives share the same options.  How should we
> solve that?  I hope that doesn't mean we still need the global
> (no)smbntsec option...

For a start, I don't think we have to go back to smbntsec.

The real problem is exactly what I describe in the comment in
fhandler_base::open().  Apparently, creating the file and sending the
security descriptor to the server is a two step approach.  So Samba
creates the file first, and then, afterwards, Windows sends the request
to change the security descriptor of the file.  Now Samba can't map
SID->uid and returns STATUS_ACCESS_DENIED.  But there seems to be no
knowledge that the two actions are actually one system call in Windows.
So Samba doesn't remove the file, but still, NtCreateFile failed.
Bummer.

I have a local workaround which I'll apply in a minute.

However, I never really understood why the mapping from the Windows
SID to the UNIX user fails, even though the user has been successfully
authenticated before.  I have written a clueless mail to the samba
developers list.  Maybe they can enlighten me.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]