这总是会发生：
我有一台装有 5 个硬盘的 Windows 10 PC，每个硬盘都用作一个分区。我将 C: 分区用于操作系统，其他分区用于数据、备份等。分区为 C:、D:、E:、F: 和 G:。
最后，我不得不格式化我的 C: 驱动器以获得全新的 Windows 安装。但麻烦太大了，我很后悔这么做：原来之前的安装为每个分区分配了一个用户身份（SID？）。现在，我只能访问 C: 驱动器，奇怪的是，D: 也一样，但不能访问 E: 到 G:。（顺便说一下，当前的 D: 是以前的 F:，驱动器号互换了）。
我检查了驱动器属性下的安全选项卡，发现“SYSTEM”和“Administrators”具有完全访问权限和控制权，以及一个以字母“S”开头的恶意“未知”帐户和一堆字符。我删除了它们。
我是这台电脑的唯一用户（拥有 Microsoft 帐户），帐户类型为“管理员”。但我仍然无法访问这些驱动器；我收到“拒绝访问”消息。问题 1：为什么？
最弱的解决方案是“个人”占有（分配基于用户的权限，但不推荐）——让我的用户（Microsoft）帐户成为所有者并拥有完全访问权限。问题是：这会将这个新身份分配给这些驱动器中的所有文件，其中一个包含我的 650GB Dropbox 文件夹，而另一个包含我同样 650GB 的 OneDrive 镜像。由于所有文件的元数据都通过此过程进行了修改，我必须再次将我的所有数据重新同步到两个云，这是不可接受的。
问题 2：下次格式化 C: 盘时，如何防止发生这种情况？
ps 我无法使用该icacls * /T /Q /C /RESET命令，因为我一开始就无权访问这些驱动器。
答案1
使用以前的 Windows 安装时，您向用户或自定义组授予了文件权限。您的新 Windows 安装对此用户/组一无所知，因此它无法显示名称，但必须显示用户/组的内部 ID（称为 SID），如下所示：S-1-5-21-555548493-16897873-2819830480-1002
如果您计划使用来自多个 Windows 安装的文件，比如使用双启动或可能在某个时候安装全新的 Windows 来替换旧安装，那么将文件权限分配给您创建的用户或组绝不是一个好主意。
如果组成员身份users对您来说不够详细，您可以使用其他内置 Windows 组来分配权限。由于这些组在每个 Windows 安装中都具有相同的内部 SID，因此文件权限保持不变。
内置组包括：
Access Control Assistance Operators S-1-5-32-579
Administrators S-1-5-32-544
Backup Operators S-1-5-32-551
Cryptographic Operators S-1-5-32-569
Distributed COM Users S-1-5-32-562
Event Log Readers S-1-5-32-573
Guests S-1-5-32-546
Hyper-V Administrators S-1-5-32-578
IIS_IUSRS S-1-5-32-568
Network Configuration Operators S-1-5-32-556
Performance Log Users S-1-5-32-559
Performance Monitor Users S-1-5-32-558
Power Users S-1-5-32-547
Remote Desktop Users S-1-5-32-555
Remote Management Users S-1-5-32-580
Replicator S-1-5-32-552
System Managed Accounts Group S-1-5-32-581
Users S-1-5-32-545
但其中许多组由于多种原因不符合此目的，我在此略过。我个人使用该组，如果授予用户 RDP 访问权限不成问题，Replicator您也可以使用该组。Remote Desktop Users
这就是未来，您当前的数据驱动器仍然有问题，您别无选择，只能将所有文件的所有权授予管理员组，然后分配所需的正确权限。您可以使用takeown.exe和icacls.exe，用有限数量的文件进行测试，然后将访问规则应用于所有文件。
由于您实际上并没有更改文件的内容，而只是更改了元数据，因此我不确定 Dropbox 是否将其视为更改。我怀疑 Dropbox 是否将 NTFS ACL 复制到云中，但我对此并不确定。