Permission denied on a windows share

Randall R Schulz rrschulz@cris.com
Sun Jul 14 08:37:00 GMT 2002


Jehan,

At 20:20 2002-07-13, Jehan wrote:
>Randall R Schulz wrote:
>
>>Jehan,
>>
>>Move ("mv") doesn't write into files. It manipulates directory entries.
>
>However, mv has to copy the file when you move it accross filesystems, 
>doesn't it? If the file was on the same partition, I would understand that 
>it works (cygwin would just ask the filesystem to move the file entry from 
>one directory to another). But in my case, the initial file is on a local 
>drive while the destination is a share. It must be copied somehow.

Yes, but mv will always remove the target and then re-create it, either by 
linking and unlinking (when the source and destination are the same file 
system) or copying and unlinking (the cross-file-system case). Cp will 
(attempt to) open an existing file and overwrite it.


>>Directory permissions and the permissions of the files they contain are 
>>not the same thing--they're mostly independent. An unwritable file is 
>>still removable (or replaceable) if the directory in which it resides 
>>permits writing (to a first approximation, at least).
>
>But if *I* create the file, I should then be able to write to it no?

Not necessarily. On Unix it would depend only on the umask you have set up. 
Windows is probably different.


>>Windows permissions are a lot...fancier than Unix's. Cygwin does its best 
>>to map permissions between the two models, but in the end, it's Windows' 
>>permission scheme that rules the day. Network shares probably complicate 
>>the picture, too, but I'm no expert on either Windows' permission scheme 
>>nor how network shares interact with it.
>>
>>This should give you the clues on where to look to solve your problem. 
>>Look at the directory's permissions and ownership with "ls -ld" and the 
>>files' with "ls -l".
>
>I know (well I think I know) what is going on. This directory belongs to 
>the domain user jehan while I'm log as the local user jehan. They are two 
>different accounts so have different IDs.
>But then, I should not be able to *create* the empty file: the directory 
>also belongs to the domain user.

I'm not sure, but I think that under Windows, creation, removal, reading, 
writing, renaming (maybe) are all governed by separate capabilities. Take 
this with a grain of salt--as I said, I don't really understand the Windows 
permissions scheme.


>I should not be able to *read* the files: the windows permission show them 
>are read/writable only by the domain user.
>
>So cygwin isn't very consistent in it's behavior. It looks like cygwin 
>relies on Windows for read permission and file creation but manages the 
>write permission itself. That cygwin tries to set the permission to have a 
>Unix like behavior ok, but that I don't think it should try to enforce 
>them, it's Windows reponsability. So I think there is definitely a bug in 
>cygwin in this regard.

Read the Cygwin Users' Guide for details on the interaction between Cygwin 
and Windows permissions. See <http://cygwin.com/cygwin-ug-net/ntsec.html> 
and <http://cygwin.com/cygwin-ug-net/using-filemodes.html>. The FAQ 
(<http://cygwin.com/faq/faq.html>) contains relevant information, too.

One thing is certain, Cygwin cannot override Windows permissions. If you 
can read (or write or remove, etc.) the file from a Cygwin application, you 
can read (write, remove) it from a Windows native app. I'm not certain the 
reverse is true, however.


Sorry to equivocate so, but since you seemed a little desperate, I figured 
I'd try to help.


>    Jehan


Randall Schulz
Mountain View, CA USA


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list