Wow, this is definitely great to know and explains it all. Awesome find,
thanks!
Steve
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
kevin
Sent: Friday, May 23, 2008 3:04 PM
To: unattended-info@lists.sourceforge.net
Subject: Re: [Unattended] Having a Problem (mapzrun)
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
