I think I may have found the issue, at least a possible related issue on my
system. Apparently the more recent versions of cygwin have stopped setting
NTFS file permissions correctly, IMO. To fix this you need to set the *CYGWIN
*environment variable to include *nontsec*.
My Computer > Properties > Advanced > Environment Variables
Find the variable *CYGWIN*, edit and remove *ntsec *if it's there and add *
nontsec*. If the *CYGWIN *variable isn't there, create it and add *nontsec*
.
Now when cygwin creates files or downloads updates from using the prepare
script it will correctly just create the file and correctly allow the file
system to set the permissions based on inheritence and not try to set
permissions based on some unix/linux idea of the way to set permissions on
Windows.
I ran into the same problem this morning, if you don't have nontsec set then
CYGWIN will incorrectly set permissions and not have the execute bit turned
on, meaning you can't run the executable files, generating an access denied
message.
Otherwise, yes, after running prepare to download programs and updates,
you'll need to reset permissions so at least the read and execute bits are
set to allow for the user/group you log into your ntinstall server from the
bootdisk.
kevin
On Thu, May 22, 2008 at 8:26 AM, kevin <[EMAIL PROTECTED]> wrote:
> On Thu, May 22, 2008 at 6:35 AM, Stephen Kojoukhine <
> [EMAIL PROTECTED]> wrote:
>
>> My share is hosted on a Windows Server 2k3 SP2 by the way. When I
>> created my install share, I assigned it the following permissions:
>>
>> Are you talking Share permissions or NTFS permissions or both?
>
>
>> NOTE: OsDeploy is a straggler group, it doesn't belong to anything else,
>> not even Users.
>>
>> That's fine.
>
>> After the permissions were set as above, I ran ./prepare. And what I
>> noticed during my troubleshooting is that the folders created inside my
>> packages and updates had their ownership changed to Administrator (not
>> Administrators) as that is the account I was using. Of course, on the
>> surface this doesn't sound like it would pose a problem (as far as I know)
>> as the other permissions above propagated just fine. However, as I mentioned
>> in my previous email, I was denied access to execute files from my Z_Share.
>>
>> File ownership in Windows means almost absolutely nothing in terms of file
> permissions or file access. You can even disallow an owner from reading a
> file or folder. However, an owner can change the permissions so they can
> access said files or folders. "guest" could be the owner of the files and
> folders and as long as the Share and NTFS permissions allowed someone at
> least read access to the folders and files, they could access them.
>
>> I'm wondering, is Windows just retarded when creating child folders/files
>> and intelligently assigning permissions? Or is it something the scripts do
>> wrong, although looking at the scripts I don't see any tinkering with
>> permissions, and can't imagine a reason to have them do so anyway.
>>
> I'd double check your permissions and make sure that your OsDeploy group
> had read permissions through the ntinstall share as well as at the NTFS
> level. But it sounds like when you reapplied ownership it reapplied the
> permissions and all is well again.
>
> I'd also make sure you're not dealing with the deny bit set on any of your
> permission settings to remove that layer of complexity.
>
> kevin
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
unattended-info mailing list
unattended-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unattended-info
