我已将 Windows 脚本从运行 2000 的机器移至运行 Windows Server 2008 R2 的新机器。
该脚本所做的第一件事是重命名与脚本位于同一文件夹中的文本文件。
相关文件的安全列表中将当前登录的用户（即管理员）设置为“完全控制”。
当我尝试通过双击来运行该脚本时（以具有该文件的完全控制权的同一管理员身份登录到计算机）我在文件重命名的行上收到“访问被拒绝”提示。
如果我通过计划任务运行脚本，它可以超越该点。
如果我通过以“管理员”身份运行的“runas”命令间接运行脚本，它就会超越这一点。
因此看起来 Windows 只是忽略了域管理员帐户对该文件的权限。
顺便说一句，我也无法保存对脚本文件的任何更改，因此我的访问也被拒绝。
知道如何阻止操作系统忽略登录用户对文件的权限吗？
编辑：回应 Gnouc 的评论，我已取得包含该脚本的文件夹和该脚本试图重命名的其他文件的所有权。现在一切正常。因此，似乎要使脚本正常工作，运行该脚本的用户需要拥有“完全控制权”并成为所有者！这似乎有点限制，但我想有人可能会认为这是因为操作系统更安全。
答案1
首先，当使用该方法运行任务时Scheduled Task，脚本将以SYSTEM帐户的身份运行，该帐户取代了Administrator帐户。在 Windows 中，管理员帐户不具有所有权限。当用户复制文件时，新文件的文件所有权和权限来自执行任务的用户。在本例中，即帐户SYSTEM。
您有两种可能的解决方案：
- 您可以更改计划任务以以特定用户身份运行。
- 您可以使用权限控制命令用于在复制文件后更改文件的所有权/权限。
答案2
由于您的系统使用 NTFS，它会将您登录会话用户的 SID 与 ACL Entry 生成的 SID 进行比较。您的脚本使用旧系统中的旧 ACL，因此它无法为您的用户评估正确的 ACL Enttry。
办法take ownership：
允许或拒绝取得文件或文件夹的所有权。文件或文件夹的所有者始终可以更改其权限，无论保护该文件或文件夹的现有权限如何。
因此脚本本身现在可以评估 ACL 条目，并为您提供正确的权限。
有关 NTFS 的更多详细信息，请参阅这里
此致。