My approach is to not use file/directory level file permissions; use file share level permissions, and set the whole server filesystem data drive to Everyone Full Control (which becomes moot).
Over the years (10+), I have found that NTFS permissions are more complex and leads to more errors. If the permissions are set wrong, or the inheritance gets broken, you expose data and its hard to find and see it. Plus, you are exposed to the move/copy problem as you say.
Places where you have to use directory/file level ACL's; I know of no other solution than health checking the thing on a regular basis.
When you "mount" winpe_amd64.iso on a VM and boot from it the ISO sees itself booting from a CD/DVD drive (either real or virtual).
When you boot winpe_amd64.iso from memdisk the ISO sees an "emulated" (created by memdisk) disk environment.
APPEND iso raw
Some Windows ISO's need the 'raw' option on some PCs.
It is possible to map and boot from some CD/DVD images using MEMDISK. No-emulation, floppy emulation and hard disk emulation ISO's are supported.
The "map" process is implemented using INT 13h - any disk emulation will remain accessible from an OS that uses compatible mode disk access, e.g. DOS and Windows 9x. The emulation via INT 13h can't however, be accessed from an OS which uses protected mode drivers (Windows NT/2000/XP/2003/Vista/2008/7, Linux, FreeBSD) once the protected mode kernel drivers take control. If the OS contains drivers for accessing this mapped ISO, or knows how to find the ISO on the disk, there is no booting problem of course.
INT 13h access: Not all images will complete the boot process!
Windows NT/2000/XP/2003/Vista/2008/7 (NT based)
These Windows versions use INT 13h access only in the start of the booting process (loading only the necessary drivers). Once the protected mode drivers are functional to access the disks, Windows can't see the memory mapped drives created by MEMDISK (CD/DVD, hard disk and floppy disk images) and it will fail to complete the boot process.
Source:
http://www.syslinux.org/wiki/index.php/MEMDISK
Bottom line: memdisk is a last resource alternative. pretty unreliable. avoid it.
In your case I'd try PXE booting into pxeboot.n12 (NBP) wich later calls bootmgr.exe, bcd, boot.sdi, and finally your Boot.wim file. This is pretty much the WDS way to PXE a Windows PE envirnment.
Edit:
pxeboot.n12 can be found within Boot.wim on any Windows DVD/ISO.
Specifically from the error you get you can also be facing this kind problem.
https://superuser.com/questions/28123/when-installing-windows-7-cdboot-error-5-appears-cannot-boot-from-cd-why
Best Answer
Okay, I think I've solved it. The problem lies in the ntfs-3g driver; it tries too hard to predict what the user wants.
I solved the problem by mounting the volume on
/mnt/windows
using the ntfs-3g driver, then copying the ntldr file out of the volume.Then, using ntfsprogs'
ntfscp
, I re-copied the file back into the file system:Then, when I did an
ntfsinfo
on it it no longer had the compressed attribute present.