Permissions issues after installing Windows 10

Permissions issues after installing Windows 10

[Brent Epp]

I recently (finally) installed Windows 10 on my system (clean install).  
All of my files are stored in on a secondary drive/partition, on which 
cygwin is also installed.  I expected to be able to just pick up where I 
left off, but I'm getting all sorts of permissions issues with cygwin.  
I did run the cygwin setup again to reinstall/upgrade.

First, I had restore my cygwin home directory from a backup, since it 
was giving me permissions errors on .bash_history, .ssh, etc, but the 
biggest headache is with git repos.  First, it gives a "fatal: unsafe 
repository" error.  If I add it to the safe directories list, it git 
still has to reindex the repo every time I run `git status`, and it 
still fails when I try to enter a commit.

It seems most or everything is owned by "Administrators".  The only way 
I've been able to fix this is to go through the Windows advanced 
permissions dialog, change the owner to my user, and set all sub-objects 
to inheritable permissions, but I'm very leery about mass changes like 
this.

Why did this happen?  And is there a better/safer/correct way to fix this?

Thanks
  - Brent

Re: Permissions issues after installing Windows 10

[Andrey Repin]

Greetings, Brent Epp!

> I recently (finally) installed Windows 10 on my system (clean install). 
> All of my files are stored in on a secondary drive/partition, on which
> cygwin is also installed.  I expected to be able to just pick up where I
> left off, but I'm getting all sorts of permissions issues with cygwin.  I
> did run the cygwin setup again to reinstall/upgrade.

> First, I had restore my cygwin home directory from a backup, since it was
> giving me permissions errors on .bash_history, .ssh, etc, but the biggest
> headache is with git repos.  First, it gives a "fatal: unsafe repository"
> error.  If I add it to the safe directories list, it git still has to
> reindex the repo every time I run `git status`, and it still fails when I try to enter a commit.

> It seems most or everything is owned by "Administrators".  The only way
> I've been able to fix this is to go through the Windows advanced permissions
> dialog, change the owner to my user, and set all sub-objects to inheritable
> permissions, but I'm very leery about mass changes like this.

> Why did this happen?  And is there a better/safer/correct way to fix this?

The only way is to install a clean copy of Cygwin and carefully copy your
changes over. This will ensure that all permissions are set correctly, and all
programs are rebased correctly as well.
This is because Windows uses a very different file access control that that of
simple POSIX permissions, on top of which Cygwin emulates them.
If you want your pain to be somewhat less in the future, move your home away
from Cygwin directory and use noacl flag on it, which will defer permissions
control to the underlying OS layer.
I'm using my Windows profile as Cygwin home, but your mileage may vary.


-- 
With best regards,
Andrey Repin
Sunday, May 8, 2022 18:32:07

Sorry for my terrible english...

Re: Permissions issues after installing Windows 10

[Brent Epp]

On 2022-05-08 10:35, Andrey Repin wrote:
> Greetings, Brent Epp!
>
>> I recently (finally) installed Windows 10 on my system (clean install).
>> All of my files are stored in on a secondary drive/partition, on which
>> cygwin is also installed.  I expected to be able to just pick up where I
>> left off, but I'm getting all sorts of permissions issues with cygwin.  I
>> did run the cygwin setup again to reinstall/upgrade.
>> First, I had restore my cygwin home directory from a backup, since it was
>> giving me permissions errors on .bash_history, .ssh, etc, but the biggest
>> headache is with git repos.  First, it gives a "fatal: unsafe repository"
>> error.  If I add it to the safe directories list, it git still has to
>> reindex the repo every time I run `git status`, and it still fails when I try to enter a commit.
>> It seems most or everything is owned by "Administrators".  The only way
>> I've been able to fix this is to go through the Windows advanced permissions
>> dialog, change the owner to my user, and set all sub-objects to inheritable
>> permissions, but I'm very leery about mass changes like this.
>> Why did this happen?  And is there a better/safer/correct way to fix this?
> The only way is to install a clean copy of Cygwin and carefully copy your
> changes over. This will ensure that all permissions are set correctly, and all
> programs are rebased correctly as well.
> This is because Windows uses a very different file access control that that of
> simple POSIX permissions, on top of which Cygwin emulates them.
> If you want your pain to be somewhat less in the future, move your home away
> from Cygwin directory and use noacl flag on it, which will defer permissions
> control to the underlying OS layer.
> I'm using my Windows profile as Cygwin home, but your mileage may vary.
Thanks, I did try a clean install of cygwin.  This has not resolved the 
issue.

I think what's happened is that some of all files modified by by various 
command line programs (git, rsync, etc.) in cygwin have ended up with 
permissions that didn't carry across with the new Windows installation.  
In the [Security] tab for these files or directories, under "Group or 
user names", it lists the owner as "Account Unknown(S-...)".  In some 
cases, these files are completely inaccessible and I can't even take 
ownership or change the permissions.  I have to either restore them from 
a backup or boot to a Linux environment to access them.

  - Brent

Re: Permissions issues after installing Windows 10

[Bill Stewart]

On Thu, Jun 2, 2022 at 6:44 AM Brent Epp wrote:

In the [Security] tab for these files or directories, under "Group or
> user names", it lists the owner as "Account Unknown(S-...)".  In some
> cases, these files are completely inaccessible and I can't even take
> ownership or change the permissions.  I have to either restore them from
> a backup or boot to a Linux environment to access them.
>

Windows displays "Account Unknown" (with a SID) in the ACL when it can't
resolve the SID reference.

There can be a number of reasons for this. One common reason is that the
SID belongs to a domain account and the domain is not accessible. Another
is that the SID belongs to a local account on a different computer (e.g., a
removable disk is moved between computers and local accounts are in the
ACL). Well-known SIDs (e.g., S-1-5-32-544 for the local Administrators
group, etc.) should resolve from any computer.

Bill

Re: Permissions issues after installing Windows 10

[Brent Epp]

On 2022-06-02 10:14, Bill Stewart wrote:
> On Thu, Jun 2, 2022 at 6:44 AM Brent Epp wrote:
>
> In the [Security] tab for these files or directories, under "Group or
>> user names", it lists the owner as "Account Unknown(S-...)".  In some
>> cases, these files are completely inaccessible and I can't even take
>> ownership or change the permissions.  I have to either restore them from
>> a backup or boot to a Linux environment to access them.
>>
> Windows displays "Account Unknown" (with a SID) in the ACL when it can't
> resolve the SID reference.
>
> There can be a number of reasons for this. One common reason is that the
> SID belongs to a domain account and the domain is not accessible. Another
> is that the SID belongs to a local account on a different computer (e.g., a
> removable disk is moved between computers and local accounts are in the
> ACL).
This is essentially what happened (removable disk moved from one 
computer to another).

> Well-known SIDs (e.g., S-1-5-32-544 for the local Administrators
> group, etc.) should resolve from any computer.
I would think so too, but that doesn't appear to be happening.If it 
makes a difference, the SID actually starts with S-1-5-21. I have to 
manually take ownership in order to even access the files at all.

  - Brent

Re: Permissions issues after installing Windows 10

[Achim Gratz]

Brent Epp writes:
> This is essentially what happened (removable disk moved from one
> computer to another).

The server resource kit from M$ used to have a tool called SubInACL that
addresses exactly this situation (among other things).  You give it a
set of old/new SID pairs and it will replace them in the objects you
tell it to modify.  I don't know if it's still available from their
downloads page, but you should still be able to find it some other
places.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Permissions issues after installing Windows 10

[Bill Stewart]

On Fri, Jun 3, 2022 at 6:23 AM Brent Epp wrote:

I would think so too, but that doesn't appear to be happening. If it
> makes a difference, the SID actually starts with S-1-5-21. I have to
> manually take ownership in order to even access the files at all.
>

Explained another way: According to
https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids -

Constant: SECURITY_NT_NON_UNIQUE
String Value: S-1-5-21
Identifies: SIDS are not unique.

SIDs starting with S-1-5-21 are non-unique, which means basically the SID
is made unique by the addition of a RID (relative identifier).

If the SID starts with S-1-5-21 and ends in 500, it is the local
"Administrator" account of some computer (or domain).

In other words, S-1-5-21 SIDs are computer or domain accounts that the
system couldn't resolve when it enumerated the ACL.

You can see SIDs for local accounts on a machine from PowerShell (all one
line):

Get-WmiObject -Query "SELECT * FROM Win32_UserAccount WHERE
LocalAccount='TRUE'" | Select-Object Name,SID

Note that in the output, these SIDs will start with S-1-5-21 and end with
various RIDs.

Bill