cygwin permissions problem on a network drive
Fri Oct 21 14:17:00 GMT 2011
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.
>>>>> ...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
> 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
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.
>>> 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
>> 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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin