Re: cygwin permissions problem on a network drive

Re: cygwin permissions problem on a network drive

[Lemke, Michael SZ/HZA-ZSW]

On Jul  5 10:59, Corinna Vinschen wrote:
>On Jul  5 12:21, Bill Metzenthen wrote:
>> I have problems with permissions on a network drive.  The drive is
>> maintained by others and I have no control over the Windows
>> permissions of the drive.
>> [...]
>> If I now try to use cygwin to create anything then it fails (despite
>> it reporting that I have rwx permissions for the directory):
>
>For now, set the mount point for this drive to "noacl".  If you're
>accessing the share via /cygdrive, create a distinct mount point for it.
>
>I know what change in Cygwin is causing that problem, but unfortunately
>I could never reproduce the server share settings myself which result in
>the permission denied.

I know this an old thread but I am in exactly the same situation as
the OP.  Access with 1.7.7 and before worked fine, 1.7.9 has this
problem.  The workaround with explicit noacl option works for me but
it is rather awkward as I have to work with a lot of servers.

So...

>...
>
>If you want to discuss this with your admin, the problem is this:  When
>Cygwin 1.7.9 tries to create a file on a filesystem which supports ACLs,
>it requests WRITE_DAC permissions in the open call.  WRITE_DAC is the
>access right you need to create the permission bits in the file's ACL,
>what you see in Explorer under the Security tab.
>
>Now, in some environments, the settings of the shares are so, that this
>right is apparently not granted, even for the creator of the file.
>But, as far as earlier reports go, there seem to be no indication of
>this in the ACL.  As I mentioned above, I experimented with this
>myself, but I have never managed to reproduce this setting on the server.
>So I neither know how this setting looks like, nor if there's a way
>to recognize such a share.
>
>So, for the time being, I will change this in Cygwin for the next
>version so that it doesn't request WRITE_DAC permissions when trying
>to create a file or directory on a network share.

...has this happened now?  In a snapshot?  I couldn't find any
further information.


Thanks,
Michael


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[gds]

On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote:

>
> I know this an old thread but I am in exactly the same situation as
> the OP.  Access with 1.7.7 and before worked fine, 1.7.9 has this
> problem.  The workaround with explicit noacl option works for me but
> it is rather awkward as I have to work with a lot of servers.
>
> So...
>

>
> ...has this happened now?  In a snapshot?  I couldn't find any
> further information.
>
>
> Thanks,
> Michael

Same problem here. Someone said snapshots here, http://cygwin.com/snapshots/ , 
fixes the problem but I tried several cygwin1.dll from there and still have 
problems.
Directory is created on network drive now but see message "can't set permissions 
... on a file" when committing with svn.
Strangely, if I commit from linux to the same mounted ntfs drive, it works.

Haven't tried the noacl method.

-gene



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[Corinna Vinschen]

On Oct 20 18:58, gds wrote:
> On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote:
> 
> >
> >I know this an old thread but I am in exactly the same situation as
> >the OP.  Access with 1.7.7 and before worked fine, 1.7.9 has this
> >problem.  The workaround with explicit noacl option works for me but
> >it is rather awkward as I have to work with a lot of servers.
> >
> >So...
> >
> 
> >
> >...has this happened now?  In a snapshot?  I couldn't find any
> >further information.
> >
> >
> >Thanks,
> >Michael
> 
> Same problem here. Someone said snapshots here,
> http://cygwin.com/snapshots/ , fixes the problem but I tried several
> cygwin1.dll from there and still have problems.
> Directory is created on network drive now but see message "can't set
> permissions ... on a file" when committing with svn.

I explained what the problem is already.  The buzzword is WRITE_DAC.
Apparently you don't have permissions to change file permissions 
on that share.  Cacls should show the exact layout of the file and
directory DACLs.  Does `chmod' work for you?  It shouldn't either.

> Strangely, if I commit from linux to the same mounted ntfs drive, it works.

Linux doesn't care for the DACL.

> Haven't tried the noacl method.

You could talk to your admin first to find out if that is by design and
maybe there could be something changed to allow changing permissions.
Otherwise, just mount the share with the noacl flag.

Again, I don't know why this happens.  I can not reproduce this problem
on my NTFS shares, other than by removing the WRITE_DAC permission from
the affected files and directories.  If there's any way to fix or
workaround it in Cygwin, somebody who has that problem has to hunt it
down.


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: cygwin permissions problem on a network drive

[Lemke, Michael SZ/HZA-ZSW]

On Friday, October 21, 2011 10:50 AM
Corinna Vinschen wrote:
>
>On Oct 20 18:58, gds wrote:
>> On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote:
>> 
>> >
>> >I know this an old thread but I am in exactly the same situation as
>> >the OP.  Access with 1.7.7 and before worked fine, 1.7.9 has this
>> >problem.  The workaround with explicit noacl option works for me but
>> >it is rather awkward as I have to work with a lot of servers.
>> >
>> >So...
>> >
>> 
>> >
>> >...has this happened now?  In a snapshot?  I couldn't find any
>> >further information.

So from the reply below I take it hasn't been fixed/worked
around in a snapshot.  But my experiments show something has
changed.  With the snapshot I can create a file, with the standard
1.7.9 dll I can't.
 
>> 
>> Same problem here. Someone said snapshots here,
>> http://cygwin.com/snapshots/ , fixes the problem but I tried several
>> cygwin1.dll from there and still have problems.
>> Directory is created on network drive now but see message "can't set
>> permissions ... on a file" when committing with svn.
>
>I explained what the problem is already.  The buzzword is WRITE_DAC.
>Apparently you don't have permissions to change file permissions 
>on that share.  Cacls should show the exact layout of the file and
>directory DACLs.  Does `chmod' work for you?  It shouldn't either.

In my case that it true, chmod fails.

>
>You could talk to your admin first to find out if that is by design and
>maybe there could be something changed to allow changing permissions.

This is by design here.  IT wants it that way.

>Otherwise, just mount the share with the noacl flag.
>
>Again, I don't know why this happens.  I can not reproduce this problem
>on my NTFS shares, other than by removing the WRITE_DAC permission from
>the affected files and directories.  If there's any way to fix or
>workaround it in Cygwin, somebody who has that problem has to hunt it
>down.
>

I am willing to try to hunt it down.  What do you want me to check?
Hm, it seems something really has changed, I can't reproduce the
problem at the moment.  I can create a file, delete it but can’t
change permissions.  The latter breaks d2u:

$> touch /u/blubb
$> d2u /u/blubb
dos2unix: Failed to change the permissions of temporary output file /u/d2utmpaF6gvB: Permission denied
dos2unix: converting file /u/blubb to Unix format ...
dos2unix: problems converting file /u/blubb
$> rm /u/blubb
rm: remove regular empty file `/u/blubb'? y
$>

Is there anything in the snapshot that could explain it?  Or
did I mess up everything here?  Confused...

Well, I just cross checked.  Reinstalled 1.7.9 and the problem
is back.  So the snapshot seems to have fixed it.  That is,
this snapshot:
CYGWIN_NT-5.1 p01080268 1.7.10s(0.253/5/3) 20111017 18:26:05 i686 Cygwin
Didn't try the latest.  With the snapshot it behaves like 1.7.7 apparently.

Michael

Re: cygwin permissions problem on a network drive

[Corinna Vinschen]

On Oct 21 12:15, Lemke, Michael  SZ/HZA-ZSW wrote:
> On Friday, October 21, 2011 10:50 AM
> Corinna Vinschen wrote:
> >
> >On Oct 20 18:58, gds wrote:
> >> On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote:
> >> 
> >> >
> >> >I know this an old thread but I am in exactly the same situation as
> >> >the OP.  Access with 1.7.7 and before worked fine, 1.7.9 has this
> >> >problem.  The workaround with explicit noacl option works for me but
> >> >it is rather awkward as I have to work with a lot of servers.
> >> >
> >> >So...
> >> >
> >> 
> >> >
> >> >...has this happened now?  In a snapshot?  I couldn't find any
> >> >further information.
> 
> So from the reply below I take it hasn't been fixed/worked
> around in a snapshot.  But my experiments show something has

Wrong.  It has been fixed in the snapshot.  1.7.9 tries to open the file
with WRITE_DAC access which fails on some shares.  The snapshots won't
do that anymore.

> >I explained what the problem is already.  The buzzword is WRITE_DAC.
> >Apparently you don't have permissions to change file permissions 
> >on that share.  Cacls should show the exact layout of the file and
> >directory DACLs.  Does `chmod' work for you?  It shouldn't either.
> 
> In my case that it true, chmod fails.

Good!  That shows that my assumption is correct.

> >You could talk to your admin first to find out if that is by design and
> >maybe there could be something changed to allow changing permissions.
> 
> This is by design here.  IT wants it that way.

Then "noacl' is the only way for you.

> >Otherwise, just mount the share with the noacl flag.
> >
> >Again, I don't know why this happens.  I can not reproduce this problem
> >on my NTFS shares, other than by removing the WRITE_DAC permission from
> >the affected files and directories.  If there's any way to fix or
> >workaround it in Cygwin, somebody who has that problem has to hunt it
> >down.
> >
> 
> I am willing to try to hunt it down.  What do you want me to check?

Check with your admin and ask how they make sure that you can't set
permissions.  Did they just create a certain set of inheritable
permissions or do they use some policy?  That is what I'd like to know.
The answer, however, will only help me to understand, it will not help
you to avoid the "noacl" setting.


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: cygwin permissions problem on a network drive

[Lemke, Michael SZ/HZA-ZSW]

On October 21, 2011 12:55 PM Corinna Vinschen wrote:
>
>On Oct 21 12:15, Lemke, Michael  SZ/HZA-ZSW wrote:
>> On Friday, October 21, 2011 10:50 AM
>> Corinna Vinschen wrote:
>> >
>> >On Oct 20 18:58, gds wrote:
>> >> On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote:
>> >> 
>> >> >
>> >> >I know this an old thread but I am in exactly the same situation as
>> >> >the OP.  Access with 1.7.7 and before worked fine, 1.7.9 has this
>> >> >problem.  The workaround with explicit noacl option works for me but
>> >> >it is rather awkward as I have to work with a lot of servers.
>> >> >
>> 
>> So from the reply below I take it hasn't been fixed/worked
>> around in a snapshot.  But my experiments show something has
>
>Wrong.  It has been fixed in the snapshot.  1.7.9 tries to open the file
>with WRITE_DAC access which fails on some shares.  The snapshots won't
>do that anymore.

Excellent.  That explains my observations.

>
>> >I explained what the problem is already.  The buzzword is WRITE_DAC.
>> >Apparently you don't have permissions to change file permissions 
>> >on that share.  Cacls should show the exact layout of the file and
>> >directory DACLs.  Does `chmod' work for you?  It shouldn't either.
>> 
>> In my case that it true, chmod fails.
>
>Good!  That shows that my assumption is correct.
>
>> 
>> This is by design here.  IT wants it that way.
>
>Then "noacl' is the only way for you.

Unless I wait for the next release, right?

>> >
>> >Again, I don't know why this happens.  I can not reproduce this problem
>> >on my NTFS shares, other than by removing the WRITE_DAC permission from
>> >the affected files and directories.  If there's any way to fix or
>> >workaround it in Cygwin, somebody who has that problem has to hunt it
>> >down.
>> >
>> 
>> I am willing to try to hunt it down.  What do you want me to check?
>
>Check with your admin and ask how they make sure that you can't set
>permissions.  Did they just create a certain set of inheritable
>permissions or do they use some policy?  That is what I'd like to know.

I don't have a definitive answer yet but it looks like it's a
policy.  In Windows Explorer I have Full Access for the top level
dir.  That is inherited by every subdir and files.  But the security
entry is greyed out, also for subdirs.

Michael

Re: cygwin permissions problem on a network drive

[gds]

On 10/21/2011 06:55 AM, Corinna Vinschen wrote:
> On Oct 21 12:15, Lemke, Michael  SZ/HZA-ZSW wrote:
>> On Friday, October 21, 2011 10:50 AM
>> Corinna Vinschen wrote:
>>>
>>> On Oct 20 18:58, gds wrote:
>>>> On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote:
>>>>
>>>>>
>>>>> I know this an old thread but I am in exactly the same situation as
>>>>> the OP.  Access with 1.7.7 and before worked fine, 1.7.9 has this
>>>>> problem.  The workaround with explicit noacl option works for me but
>>>>> it is rather awkward as I have to work with a lot of servers.
>>>>>
>>>>> So...
>>>>>
>>>>
>>>>>
>>>>> ...has this happened now?  In a snapshot?  I couldn't find any
>>>>> further information.
>>
>> So from the reply below I take it hasn't been fixed/worked
>> around in a snapshot.  But my experiments show something has
>
> Wrong.  It has been fixed in the snapshot.  1.7.9 tries to open the file
> with WRITE_DAC access which fails on some shares.  The snapshots won't
> do that anymore.
>
>>> I explained what the problem is already.  The buzzword is WRITE_DAC.
>>> Apparently you don't have permissions to change file permissions
>>> on that share.  Cacls should show the exact layout of the file and
>>> directory DACLs.  Does `chmod' work for you?  It shouldn't either.
>>
>> In my case that it true, chmod fails.

For me chmod *appears* to work (no errors on cmd line) but file permissions seen
in "ls -l" don't change nor do they change in windows. Also, in windows, I can't 
change any of my access rights; under file properties/security under "allow" all 
are checked except Full Control and Special permissions, none checked under 
"Deny" and all check marks are gray so I can't change them there either. Anyone 
can create, modify or delete any file, but no one can hide or write-protect any 
file (which would require changing permission/access rights).

AFAIK, this is how it has always been on this share. If this assumption is 
correct, does that mean something changed in cygwin that is causing this 
possible bug?

>
> Good!  That shows that my assumption is correct.
>
>>> You could talk to your admin first to find out if that is by design and
>>> maybe there could be something changed to allow changing permissions.
>>
>> This is by design here.  IT wants it that way.

I think ours is the same way but haven't asked. (Using cygwin for what I am 
doing "not approved" here :().

>
> Then "noacl' is the only way for you.

Yes, no snapshot cygwin1.dll helped. Went back to default. Now have only this in 
/etc/fstab:

O: /my-o-drive	dontcare binary,noacl 0 0

So now access drive with /my-o-drive instead of /cygdrive/o

>
>>> Otherwise, just mount the share with the noacl flag.

Doing it.

>>>
>>> Again, I don't know why this happens.  I can not reproduce this problem
>>> on my NTFS shares, other than by removing the WRITE_DAC permission from
>>> the affected files and directories.  If there's any way to fix or
>>> workaround it in Cygwin, somebody who has that problem has to hunt it
>>> down.
>>>
>>
>> I am willing to try to hunt it down.  What do you want me to check?
>
> Check with your admin and ask how they make sure that you can't set
> permissions.  Did they just create a certain set of inheritable
> permissions or do they use some policy?  That is what I'd like to know.
> The answer, however, will only help me to understand, it will not help
> you to avoid the "noacl" setting.
>
>
> Corinna
>



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[Corinna Vinschen]

On Oct 21 16:13, Lemke, Michael  SZ/HZA-ZSW wrote:
> On October 21, 2011 12:55 PM Corinna Vinschen wrote:
> >On Oct 21 12:15, Lemke, Michael  SZ/HZA-ZSW wrote:
> >> This is by design here.  IT wants it that way.
> >
> >Then "noacl' is the only way for you.
> 
> Unless I wait for the next release, right?

No.  If you don't want to get a "Permission denied" error messages every
time some application tries to change the permissions, you will have to
use "noacl".  It seems you don't understand what "acl" vs. "noacl" is
for.  Does reading the User's Guide at
http://cygwin.com/cygwin-ug-net/using.html#mount-table help?

> >Check with your admin and ask how they make sure that you can't set
> >permissions.  Did they just create a certain set of inheritable
> >permissions or do they use some policy?  That is what I'd like to know.
> 
> I don't have a definitive answer yet but it looks like it's a
> policy.  In Windows Explorer I have Full Access for the top level
> dir.  That is inherited by every subdir and files.  But the security
> entry is greyed out, also for subdirs.

Ok, so there is some sort of policy.  It would be nice to get some
"how to set up a share policy which doesn't allow changing permissions
 for dummies" :)


Thanks,
Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[Corinna Vinschen]

On Oct 21 10:16, gds wrote:
> On 10/21/2011 06:55 AM, Corinna Vinschen wrote:
> >On Oct 21 12:15, Lemke, Michael  SZ/HZA-ZSW wrote:
> >>On Friday, October 21, 2011 10:50 AM
> >>Corinna Vinschen wrote:
> >>>
> >>>On Oct 20 18:58, gds wrote:
> >>>>On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote:
> >>>>
> >>>>>
> >>>>>I know this an old thread but I am in exactly the same situation as
> >>>>>the OP.  Access with 1.7.7 and before worked fine, 1.7.9 has this
> >>>>>problem.  The workaround with explicit noacl option works for me but
> >>>>>it is rather awkward as I have to work with a lot of servers.
> >>>>>
> >>>>>So...
> >>>>>
> >>>>
> >>>>>
> >>>>>...has this happened now?  In a snapshot?  I couldn't find any
> >>>>>further information.
> >>
> >>So from the reply below I take it hasn't been fixed/worked
> >>around in a snapshot.  But my experiments show something has
> >
> >Wrong.  It has been fixed in the snapshot.  1.7.9 tries to open the file
> >with WRITE_DAC access which fails on some shares.  The snapshots won't
> >do that anymore.
> >
> >>>I explained what the problem is already.  The buzzword is WRITE_DAC.
> >>>Apparently you don't have permissions to change file permissions
> >>>on that share.  Cacls should show the exact layout of the file and
> >>>directory DACLs.  Does `chmod' work for you?  It shouldn't either.
> >>
> >>In my case that it true, chmod fails.
> 
> For me chmod *appears* to work (no errors on cmd line) but file
> permissions seen in "ls -l" don't change nor do they change in
> windows.

This is *with* using the "noacl" mount option, isn't it?  Without
the "noacl" option you should get a "Permission denied" on chmod.

> Also, in
> windows, I can't change any of my access rights; under file
> properties/security under "allow" all are checked except Full
> Control and Special permissions, none checked under "Deny" and all
> check marks are gray so I can't change them there either. Anyone can
> create, modify or delete any file, but no one can hide or
> write-protect any file (which would require changing
> permission/access rights).
> 
> AFAIK, this is how it has always been on this share. If this
> assumption is correct, does that mean something changed in cygwin
> that is causing this possible bug?

I explained that in this thread.  WRITE_DAC vs. not WRITE_DAC.

> >Then "noacl' is the only way for you.
> 
> Yes, no snapshot cygwin1.dll helped. Went back to default. Now have
> only this in /etc/fstab:
> 
> O: /my-o-drive	dontcare binary,noacl 0 0
> 
> So now access drive with /my-o-drive instead of /cygdrive/o

Yes, that's how it's supposed to be in your situation.


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: cygwin permissions problem on a network drive

[Lemke, Michael SZ/HZA-ZSW]

On October 21, 2011 4:36 PM Corinna Vinschen wrote:
>On Oct 21 16:13, Lemke, Michael  SZ/HZA-ZSW wrote:
>> On October 21, 2011 12:55 PM Corinna Vinschen wrote:
>> >On Oct 21 12:15, Lemke, Michael  SZ/HZA-ZSW wrote:
>> >> This is by design here.  IT wants it that way.
>> >
>> >Then "noacl' is the only way for you.
>> 
>> Unless I wait for the next release, right?
>
>No.  If you don't want to get a "Permission denied" error messages every
>time some application tries to change the permissions, you will have to
>use "noacl".  It seems you don't understand what "acl" vs. "noacl" is
>for.  Does reading the User's Guide at
>http://cygwin.com/cygwin-ug-net/using.html#mount-table help?

No, that's not my problem.  I am fine with the error message, it's
correct after all.  The real problem with 1.7.9 is that I can't create 
files although the permissions allow me to.  And that seems to be fixed.

>
>> >Check with your admin and ask how they make sure that you can't set
>> >permissions.  Did they just create a certain set of inheritable
>> >permissions or do they use some policy?  That is what I'd like to know.
>> 
>> I don't have a definitive answer yet but it looks like it's a
>> policy.  In Windows Explorer I have Full Access for the top level
>> dir.  That is inherited by every subdir and files.  But the security
>> entry is greyed out, also for subdirs.
>
>Ok, so there is some sort of policy.  It would be nice to get some
>"how to set up a share policy which doesn't allow changing permissions
> for dummies" :)

I'll see if I can get more from our admins.

Michael

Re: cygwin permissions problem on a network drive

[gds]

On 10/21/2011 10:39 AM, Corinna Vinschen wrote:
> On Oct 21 10:16, gds wrote:
>> On 10/21/2011 06:55 AM, Corinna Vinschen wrote:
>>> On Oct 21 12:15, Lemke, Michael  SZ/HZA-ZSW wrote:
>>>> On Friday, October 21, 2011 10:50 AM
>>>> Corinna Vinschen wrote:
>>>>>
>>>>> On Oct 20 18:58, gds wrote:
>>>>>> On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote:
>>>>>>
>>>>>>>
>>>>>>> I know this an old thread but I am in exactly the same situation as
>>>>>>> the OP.  Access with 1.7.7 and before worked fine, 1.7.9 has this
>>>>>>> problem.  The workaround with explicit noacl option works for me but
>>>>>>> it is rather awkward as I have to work with a lot of servers.
>>>>>>>
>>>>>>> So...
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>> ...has this happened now?  In a snapshot?  I couldn't find any
>>>>>>> further information.
>>>>
>>>> So from the reply below I take it hasn't been fixed/worked
>>>> around in a snapshot.  But my experiments show something has
>>>
>>> Wrong.  It has been fixed in the snapshot.  1.7.9 tries to open the file
>>> with WRITE_DAC access which fails on some shares.  The snapshots won't
>>> do that anymore.
>>>
>>>>> I explained what the problem is already.  The buzzword is WRITE_DAC.
>>>>> Apparently you don't have permissions to change file permissions
>>>>> on that share.  Cacls should show the exact layout of the file and
>>>>> directory DACLs.  Does `chmod' work for you?  It shouldn't either.
>>>>
>>>> In my case that it true, chmod fails.
>>
>> For me chmod *appears* to work (no errors on cmd line) but file
>> permissions seen in "ls -l" don't change nor do they change in
>> windows.
>
> This is *with* using the "noacl" mount option, isn't it?  Without
> the "noacl" option you should get a "Permission denied" on chmod.

Actually, I thought I was in normal mount mode with acl enabled but not sure. So 
tried experiment again...

Right now, my mount shows this for o: drive:
O: on /my-o-drive type ntfs (binary,noacl)

I can cd to /my-o-drive/home/gds and do:
rm testfile
echo 1 > testfile
cat testfile
1
rm -rf testdir
mkdir testdir

and all work.

If I do chmod 000 testfile I see with ls -l:
-r--r--r--
If I do chmod 777 testfile I see
-rw-r--r--
So there is a small effect but not much.

Now I change the mount so I see (the default):
O: on /cygdrive/o type ntfs (binary,posix=0,user,nounmount,auto)

and repeat the exercise (testfile and testdir previously deleted:

cd /cygdrive/o/home/gds
echo 1 > testfile
bash: testfile: Permission denied
mkdir testdir
mkdir: cannot create directory `testdir': Permission denied

This is with the current default cygwin1.dll, not a snapshot.

So apparently, only with the noacl style mount can I create files or dirs via 
cygwin. And definitely if app using cygwin tries to change a permission, 
currently noacl is required.

Apparently Michael Lemke is saying with a SS dll you can at least create 
files/dir via cygwin (that I may have also seen when I tried a SS dll, not 
sure). However, for me, I have to now use the the noacl mount method since my 
application (svn) needs to create files and dirs on the share and it also tries 
to set permissions.

Sorry, in reading your previous explanations (quoted below), I am still not sure 
whether you are saying this new behavior is a feature or bug in cygwin, a bug in 
my app using cygwin (e.g., svn) something changed in windows setup of 
permissions. Just to put it here (since thread has become separated) here is 
what you said previously:

<begin quote, Corinna>
I know what change in Cygwin is causing that problem, but unfortunately
I could never reproduce the server share settings myself which result in
the permission denied.

<some snipped>

If you want to discuss this with your admin, the problem is this:  When
Cygwin 1.7.9 tries to create a file on a filesystem which supports ACLs,
it requests WRITE_DAC permissions in the open call.  WRITE_DAC is the
access right you need to create the permission bits in the file's ACL,
what you see in Explorer under the Security tab.

Now, in some environments, the settings of the shares are so, that this
right is apparently not granted, even for the creator of the file.
But, as far as earlier reports go, there seem to be no indication of
this in the ACL.  As I mentioned above, I experimented with this
myself, but I have never managed to reproduce this setting on the server.
So I neither know how this setting looks like, nor if there's a way
to recognize such a share.

So, for the time being, I will change this in Cygwin for the next
version so that it doesn't request WRITE_DAC permissions when trying
to create a file or directory on a network share.

The result will be that every file creation on a network share with ACL
support will try to open the file twice, the first time to create it,
the second time to set the POSIX permissions.  This slows down remote
file creation again, but I don't see a useful way around it.  Testing
for an access denied error afterwards and trying again is rather
awkward.
<end quote, Corinna>

Anyhow, with the workaround of using noacl mount, it is working OK for me. Let 
me know if there is anything more specific I can check. Thanks!

>
>> Also, in
>> windows, I can't change any of my access rights; under file
>> properties/security under "allow" all are checked except Full
>> Control and Special permissions, none checked under "Deny" and all
>> check marks are gray so I can't change them there either. Anyone can
>> create, modify or delete any file, but no one can hide or
>> write-protect any file (which would require changing
>> permission/access rights).
>>
>> AFAIK, this is how it has always been on this share. If this
>> assumption is correct, does that mean something changed in cygwin
>> that is causing this possible bug?
>
> I explained that in this thread.  WRITE_DAC vs. not WRITE_DAC.

Thanks, copied it above.

>
>>> Then "noacl' is the only way for you.
>>
>> Yes, no snapshot cygwin1.dll helped. Went back to default. Now have
>> only this in /etc/fstab:
>>
>> O: /my-o-drive	dontcare binary,noacl 0 0
>>
>> So now access drive with /my-o-drive instead of /cygdrive/o
>
> Yes, that's how it's supposed to be in your situation.
>
>
> Corinna
>



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[Corinna Vinschen]

On Oct 21 12:32, gds wrote:
> 
> If I do chmod 000 testfile I see with ls -l:
> -r--r--r--
> If I do chmod 777 testfile I see
> -rw-r--r--
> So there is a small effect but not much.

In noacl mode or on file systems not supporting ACLs (FAT, for instance)
permissions are emulated using the DOS R/O bit to set the write flag
and file suffixes and magic numbers to emulate the execute bit.  That's
what you see above.  That's actually documented in the User's Guide:
http://cygwin.com/cygwin-ug-net/using-filemodes.html

> Sorry, in reading your previous explanations (quoted below), I am
> still not sure whether you are saying this new behavior is a feature
> or bug in cygwin, a bug in my app using cygwin (e.g., svn) something
> changed in windows setup of permissions. Just to put it here (since
> thread has become separated) here is what you said previously:

It's a bug in 1.7.9 that you can't create files in this scenario.
It's fixed in CVS.  It's not a bug in 1.7.9, nor in CVS, that an
application gets a "Permission denied" error when it tries to change
file permissions in this scenario.


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[Corinna Vinschen]

On Jan  4 15:25, Markus Leuthold wrote:
> On Jul  5 10:59, Corinna Vinschen wrote:
> >On Jul  5 12:21, Bill Metzenthen wrote:
> >> What should I ask the system administrator to change so that cygwin
> >> will once again work on this drive? Perhaps there is some new setting
> >> (or an old one which has somehow changed) for cygwin that I have
> >> failed to notice?
> >
> >If you want to discuss this with your admin, the problem is this:  When
> >Cygwin 1.7.9 tries to create a file on a filesystem which supports ACLs,
> >it requests WRITE_DAC permissions in the open call.  WRITE_DAC is the
> >access right you need to create the permission bits in the file's ACL,
> >what you see in Explorer under the Security tab.
> >
> >Now, in some environments, the settings of the shares are so, that this
> >right is apparently not granted, even for the creator of the file.
> >But, as far as earlier reports go, there seem to be no indication of
> >this in the ACL.  As I mentioned above, I experimented with this
> >myself, but I have never managed to reproduce this setting on the
> server.
> >So I neither know how this setting looks like, nor if there's a way
> >to recognize such a share.
> >
> >Btw, if you're going to discuss this with your admin, and if you figure
> >out what server setting is the culprit, I would be glad if you could
> >share the information with us.  It might be a great help in developing
> >Cygwin further.
> >
> >
> >Thanks,
> >Corinna
> 
> 
> Hello Corinna
> 
> I've run into the same problem on a DFS filesystem, and I asked our
> admins about the settings. Please find a screenshot here:
> http://titlis.org/serversettings.png
> 
> The reason why "change permission" (=WRITE_DAC) was disabled: Our
> admins don't want to allow "take ownership" to everybody, since in
> the past users managed to set the rights such that even the admins
> couldn't access the file anymore. Since "take ownership"
> automatically enables "change permissions", WRITE_DAC is thus
> disabled too.
> 
> hope that helps

Thanks for the info.


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[Markus Leuthold]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2032 bytes --]

On Jul  5 10:59, Corinna Vinschen wrote:
> On Jul  5 12:21, Bill Metzenthen wrote:
> > What should I ask the system administrator to change so that cygwin
> > will once again work on this drive? Perhaps there is some new setting
> > (or an old one which has somehow changed) for cygwin that I have
> > failed to notice?
>
> If you want to discuss this with your admin, the problem is this:  When
> Cygwin 1.7.9 tries to create a file on a filesystem which supports ACLs,
> it requests WRITE_DAC permissions in the open call.  WRITE_DAC is the
> access right you need to create the permission bits in the file's ACL,
> what you see in Explorer under the Security tab.
>
> Now, in some environments, the settings of the shares are so, that this
> right is apparently not granted, even for the creator of the file.
> But, as far as earlier reports go, there seem to be no indication of
> this in the ACL.  As I mentioned above, I experimented with this
> myself, but I have never managed to reproduce this setting on the 
server.
> So I neither know how this setting looks like, nor if there's a way
> to recognize such a share.
>
>Btw, if you're going to discuss this with your admin, and if you figure
>out what server setting is the culprit, I would be glad if you could
>share the information with us.  It might be a great help in developing
>Cygwin further.
>
>
>Thanks,
>Corinna


Hello Corinna

I've run into the same problem on a DFS filesystem, and I asked our 
admins about the settings. Please find a screenshot here: 
http://titlis.org/serversettings.png

The reason why "change permission" (=WRITE_DAC) was disabled: Our admins 
don't want to allow "take ownership" to everybody, since in the past users 
managed to set the rights such that even the admins couldn't access the 
file anymore. Since "take ownership" automatically enables "change 
permissions", WRITE_DAC is thus disabled too.

hope that helps

best regards, Kusi

PS: your workaround works fine, too




[-- Attachment #2: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[Larry Hall (Cygwin)]

On 8/2/2011 12:10 PM, spambouncer@gmx.de wrote:
>> On Jul  6 11:43, Bill Metzenthen wrote:
>>> Corinna Vinschen wrote:
>>>>> If I now try to use cygwin to create anything then it fails (despite
>>>>> it reporting that I have rwx permissions for the directory):
>>>>
>>>> For now, set the mount point for this drive to "noacl".  If you're
>>>> accessing the share via /cygdrive, create a distinct mount point for it.
>>>
>>> I'm not sure that I'm doing this the right way.
>>
>> No.  I meant a distinct mount point, *different* from your cygdrive
>> prefix.  See http://cygwin.com/cygwin-ug-net/using.html#cygdrive
>>
>> This works:
>>
>>    H: /h xyz binary,noacl 0 0
>>    none /mnt cygdrive binary,posix=0,user 0 0
>>
>> Or this:
>>
>>    H: /myhome xyz binary,noacl 0 0
>>    none / cygdrive binary,posix=0,user 0 0
>>
>> Corinna
>
>
> I'm having the same problems with my $HOME folder, which is on a network
> share. I was able to create an extra mount point for the location,
> unfortunately that didn't help with the original $HOME. Could you please
> describe what I have to do circumvent the permission problem for $HOME?

Access you $HOME folder through the new mount point (i.e. /h or /myhome)
and you should be all set.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[spambouncer]

> On Jul  6 11:43, Bill Metzenthen wrote:
> > Corinna Vinschen wrote:
> > >> If I now try to use cygwin to create anything then it fails (despite
> > >> it reporting that I have rwx permissions for the directory):
> > >
> > > For now, set the mount point for this drive to "noacl".  If you're
> > > accessing the share via /cygdrive, create a distinct mount point for it.
> > 
> > I'm not sure that I'm doing this the right way.
> 
> No.  I meant a distinct mount point, *different* from your cygdrive
> prefix.  See http://cygwin.com/cygwin-ug-net/using.html#cygdrive
> 
> This works:
> 
>   H: /h xyz binary,noacl 0 0 
>   none /mnt cygdrive binary,posix=0,user 0 0
> 
> Or this:
> 
>   H: /myhome xyz binary,noacl 0 0 
>   none / cygdrive binary,posix=0,user 0 0
> 
> Corinna


I'm having the same problems with my $HOME folder, which is on a network share. I was able to create an extra mount point for the location, unfortunately that didn't help with the original $HOME. Could you please describe what I have to do circumvent the permission problem for $HOME?

Thanks a lot,
Spam Bouncer



-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[Corinna Vinschen]

On Jul  6 11:43, Bill Metzenthen wrote:
> Corinna Vinschen wrote:
> >> If I now try to use cygwin to create anything then it fails (despite
> >> it reporting that I have rwx permissions for the directory):
> >
> > For now, set the mount point for this drive to "noacl".  If you're
> > accessing the share via /cygdrive, create a distinct mount point for it.
> 
> I'm not sure that I'm doing this the right way.

No.  I meant a distinct mount point, *different* from your cygdrive
prefix.  See http://cygwin.com/cygwin-ug-net/using.html#cygdrive

This works:

  H: /h xyz binary,noacl 0 0 
  none /mnt cygdrive binary,posix=0,user 0 0

Or this:

  H: /myhome xyz binary,noacl 0 0 
  none / cygdrive binary,posix=0,user 0 0


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[Bill Metzenthen]

Corinna Vinschen wrote:
>> If I now try to use cygwin to create anything then it fails (despite
>> it reporting that I have rwx permissions for the directory):
>
> For now, set the mount point for this drive to "noacl".  If you're
> accessing the share via /cygdrive, create a distinct mount point for it.

I'm not sure that I'm doing this the right way.

I created an entry in /etc/fstab and then I got:
$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
H: on /h type ntfs (binary,noacl,posix=0,user)
C: on /c type ntfs (binary,posix=0,user,noumount,auto)

Unfortunately, this didn't fix my problem.

So then for some reason I don't remember, I commented out the
following line from /etc/fstab:
none / cygdrive binary,posix=0,user 0 0

This resulted in my being able to create directories and files on the
network drive.  It came at a cost however because C: was now mounted
on /cydrive/c, so I added and explicit entry for the C: drive in
/etc/fstab and this appears to have fixed the problem:
$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /c type ntfs (binary,posix=0,user)
H: on /h type ntfs (binary,noacl,posix=0,user)

This has the minor problem that it allows me to get into a mess by umounting /c

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[Corinna Vinschen]

On Jul  5 10:59, Corinna Vinschen wrote:
> On Jul  5 12:21, Bill Metzenthen wrote:
> > What should I ask the system administrator to change so that cygwin
> > will once again work on this drive?  Perhaps there is some new setting
> > (or an old one which has somehow changed) for cygwin that I have
> > failed to notice?
> 
> If you want to discuss this with your admin, the problem is this:  When
> Cygwin 1.7.9 tries to create a file on a filesystem which supports ACLs,
> it requests WRITE_DAC permissions in the open call.  WRITE_DAC is the
> access right you need to create the permission bits in the file's ACL,
> what you see in Explorer under the Security tab.
> 
> Now, in some environments, the settings of the shares are so, that this
> right is apparently not granted, even for the creator of the file.
> But, as far as earlier reports go, there seem to be no indication of
> this in the ACL.  As I mentioned above, I experimented with this
> myself, but I have never managed to reproduce this setting on the server.
> So I neither know how this setting looks like, nor if there's a way
> to recognize such a share.

Btw, if you're going to discuss this with your admin, and if you figure
out what server setting is the culprit, I would be glad if you could
share the information with us.  It might be a great help in developing
Cygwin further.


Thanks,
Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin permissions problem on a network drive

[Corinna Vinschen]

On Jul  5 12:21, Bill Metzenthen wrote:
> I have problems with permissions on a network drive.  The drive is
> maintained by others and I have no control over the Windows
> permissions of the drive.
> [...]
> If I now try to use cygwin to create anything then it fails (despite
> it reporting that I have rwx permissions for the directory):

For now, set the mount point for this drive to "noacl".  If you're
accessing the share via /cygdrive, create a distinct mount point for it.

I know what change in Cygwin is causing that problem, but unfortunately
I could never reproduce the server share settings myself which result in
the permission denied.

> Windows Explorer reports that the subdirectories (but not files) are
> read-only but silently fails to remove its read-only flag if I try
> that.

That's unrelated.  The R/O flag on directories is ignored by Windows
anyway, see http://support.microsoft.com/kb/326549

> It reports that I have all permissions but not 'Full Control'.

That's ok, usually.

> What should I ask the system administrator to change so that cygwin
> will once again work on this drive?  Perhaps there is some new setting
> (or an old one which has somehow changed) for cygwin that I have
> failed to notice?

If you want to discuss this with your admin, the problem is this:  When
Cygwin 1.7.9 tries to create a file on a filesystem which supports ACLs,
it requests WRITE_DAC permissions in the open call.  WRITE_DAC is the
access right you need to create the permission bits in the file's ACL,
what you see in Explorer under the Security tab.

Now, in some environments, the settings of the shares are so, that this
right is apparently not granted, even for the creator of the file.
But, as far as earlier reports go, there seem to be no indication of
this in the ACL.  As I mentioned above, I experimented with this
myself, but I have never managed to reproduce this setting on the server.
So I neither know how this setting looks like, nor if there's a way
to recognize such a share.

So, for the time being, I will change this in Cygwin for the next
version so that it doesn't request WRITE_DAC permissions when trying
to create a file or directory on a network share.

The result will be that every file creation on a network share with ACL
support will try to open the file twice, the first time to create it,
the second time to set the POSIX permissions.  This slows down remote
file creation again, but I don't see a useful way around it.  Testing
for an access denied error afterwards and trying again is rather
awkward.


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

cygwin permissions problem on a network drive

[Bill Metzenthen]

I have problems with permissions on a network drive.  The drive is
maintained by others and I have no control over the Windows
permissions of the drive.

I have a directory on the drive and I can use Windows Explorer to
create and write files and subdirectories to it.  I can also use the
Windows 'mkdir' and 'copy' commands to create directories and write
files on the drive.

Until recently I could do the same things from cygwin.  But that has changed...

If I cd in cygwin to a empty subdirectory I have created on the drive
then I find:

$ ls -la
total 0
drwx------+ 1 bmetzenthen Domain Users 0 Jul  4 11:51 .
drwx------+ 1 bmetzenthen Domain Users 0 Jul  4 11:52 ..

Where 'bmetzenthen' is me:

$ whoami
bmetzenthen

If I now try to use cygwin to create anything then it fails (despite
it reporting that I have rwx permissions for the directory):

$ mkdir test
mkdir: cannot create directory `test': Permission denied

Similarly for 'touch':

$ touch test
touch: cannot touch `test': Permission denied

If a subdirectory (or a file) is created by Windows Explorer then
'rmdir test' works.  Similarly 'touch test' and 'mv test test2'.

Windows Explorer reports that the subdirectories (but not files) are
read-only but silently fails to remove its read-only flag if I try
that.  It reports that I have all permissions but not 'Full Control'.

My cygwin installation is up to date and cygcheck -c reports all packages as OK.

What should I ask the system administrator to change so that cygwin
will once again work on this drive?  Perhaps there is some new setting
(or an old one which has somehow changed) for cygwin that I have
failed to notice?

Bill Metzenthen

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple