X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: gds Subject: Re: cygwin permissions problem on a network drive Date: Fri, 21 Oct 2011 12:32:01 -0400 Lines: 165 Message-ID: References: <20111021085010 DOT GF13505 AT calimero DOT vinschen DOT de> <20111021105510 DOT GC2979 AT calimero DOT vinschen DOT de> <20111021143913 DOT GE2976 AT calimero DOT vinschen DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110906 Fedora/3.1.14-1.fc14 Thunderbird/3.1.14 In-Reply-To: <20111021143913.GE2976@calimero.vinschen.de> X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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: 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. 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. 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