Windows 10 permissions wrecked after OS reinstall

Question

this ALWAYS happens:

I have a Windows 10 PC with five hard drives, each one functioning as a partition. I use the C: partition for the OS and the others for data, backup, and so on. The partitions are C:, D:, E:, F: and G:.

Eventually I had to format my C: drive to get a fresh Windows installation. But the hassle was so strong I regret doing that: turns out the previous installation assigned an user identity to each partition (SID?). Now, I can only access the C: drive and, curiously, the D:, but not the E: to G:. (By the way, the current D: is the former F:, which got the drive letters swapped).

I inspect the security tab under the properties of the drive, and I see 'SYSTEM' and 'Administrators' have full access and control, as well as a rogue "unknown" account beginning with letter "S" and a bunch of characters. I deleted those.

I am the only user of this computer (with a Microsoft account) and the account type is 'Administrator'. But I still can't access those drives; I get an 'Access denied' message. Question 1: Why is that?

The weak solution is to take 'personally' possession (assign a user-based permission, which is not recommended) – have my user (Microsoft) account become the owner and have full access. The problem is: this assigns this new identity to ALL files in those drives, and one contains my 650GB Dropbox folder, while the other contains my equally 650GB OneDrive mirror. Since all files' metadata are modified with this procedure, I have to resync ALL my data to both clouds all over again, which is unacceptable.

Question 2: How can I prevent this from happening next time I format my C: drive?

p.s. I can't use the icacls * /T /Q /C /RESET command because I don't have access to those drives to begin with.

Answer 1

While using your previous Windows installation, you gave file permissions to a user or a custom group. Your new Windows installation doesn't know anything about this user/group that's why it couldn't show the name but had to show the internal id (called SID) of the user/group something like: S-1-5-21-555548493-16897873-2819830480-1002

If you plan to use your files from more than one Windows installation, say using dual-boot or may install a fresh Windows at some time replacing the old installation, it is never a good idea to assign file permissions to a user or a group you created.

If membership of the users group is not granular enough for you, you can use other builtin windows groups to assign permissions. Because these groups have the same internal SIDs on every Windows installation, the file permissions stay intact.

Builtin groups are:

 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

but many of these groups are not eligible for the purpose because of several reasons which I'm skipping here. Personally I use the Replicator group, you could also use the Remote Desktop Users group, if giving the user RDP access is not a problem.

That's all about the future, you current data drives still have a problem, you have no choice but giving the Administrators group ownership of all files and then assign the desired correct permissions. You would use takeown.exe and icacls.exe, test this with a limited number of files and then apply your access rules to all files.

As you don't actually change the content of the files, just the meta data, I'm not sure Dropbox even sees that as a change. I doubt Dropbox is copying the NTFS ACLs into the cloud, but I'm not sure about that.