Hello,
I can perfectly write a file in a directory of disk E:\ but not on the
root of the very same disk. I tried disabling the UAC but I still get
the 0x80070522 error.
What could I do?
Thanks.

On 21/05/2021 16:08, Bibi69 wrote:
> Hello,
> I can perfectly write a file in a directory of disk E:\ but not on the
> root of the very same disk. I tried disabling the UAC but I still get
> the 0x80070522 error.
> What could I do?
> Thanks.

Take ownership of E:\ maybe?

Do something like:

takeown /F E:\

or maybe:

takeown /F E:\ /R

from an elevated cmd prompt.

--
Brian Gregory (in England).

Le 21/05/2021 à 17:53, Brian Gregory a écrit :
> On 21/05/2021 16:08, Bibi69 wrote:
>> Hello,
>> I can perfectly write a file in a directory of disk E:\ but not on the
>> root of the very same disk. I tried disabling the UAC but I still get
>> the 0x80070522 error.
>> What could I do?
>> Thanks.
>
> Take ownership of E:\ maybe?
>
> Do something like:
>
> takeown /F E:\
>
> or maybe:
>
> takeown /F E:\ /R
>
> from an elevated cmd prompt.
>
It didn't work.

On 21/05/2021 18:34, Bibi69 wrote:
>
>
> Le 21/05/2021 à 17:53, Brian Gregory a écrit :
>> On 21/05/2021 16:08, Bibi69 wrote:
>>> Hello,
>>> I can perfectly write a file in a directory of disk E:\ but not on
>>> the root of the very same disk. I tried disabling the UAC but I still
>>> get the 0x80070522 error.
>>> What could I do?
>>> Thanks.
>>
>> Take ownership of E:\ maybe?
>>
>> Do something like:
>>
>> takeown /F E:\
>>
>> or maybe:
>>
>> takeown /F E:\ /R
>>
>> from an elevated cmd prompt.
>>
> It didn't work.

Did you get an error message?

--
Brian Gregory (in England).

On 21/05/2021 18:34, Bibi69 wrote:
>
>
> Le 21/05/2021 à 17:53, Brian Gregory a écrit :
>> On 21/05/2021 16:08, Bibi69 wrote:
>>> Hello,
>>> I can perfectly write a file in a directory of disk E:\ but not on
>>> the root of the very same disk. I tried disabling the UAC but I still
>>> get the 0x80070522 error.
>>> What could I do?
>>> Thanks.
>>
>> Take ownership of E:\ maybe?
>>
>> Do something like:
>>
>> takeown /F E:\
>>
>> or maybe:
>>
>> takeown /F E:\ /R
>>
>> from an elevated cmd prompt.
>>
> It didn't work.

Try this from an elevated cmd prompt:

icacls E:\ /grant .:(F)

The . means you - whoever you logged in as.
You can replace the . with the word users or with the word everyone if
you wish.

--
Brian Gregory (in England).

Brian Gregory wrote:
> On 21/05/2021 18:34, Bibi69 wrote:
>>
>>
>> Le 21/05/2021 à 17:53, Brian Gregory a écrit :
>>> On 21/05/2021 16:08, Bibi69 wrote:
>>>> Hello,
>>>> I can perfectly write a file in a directory of disk E:\ but not on
>>>> the root of the very same disk. I tried disabling the UAC but I
>>>> still get the 0x80070522 error.
>>>> What could I do?
>>>> Thanks.
>>>
>>> Take ownership of E:\ maybe?
>>>
>>> Do something like:
>>>
>>> takeown /F E:\
>>>
>>> or maybe:
>>>
>>> takeown /F E:\ /R
>>>
>>> from an elevated cmd prompt.
>>>
>> It didn't work.
>
> Try this from an elevated cmd prompt:
>
> icacls E:\ /grant .:(F)
>
> The . means you - whoever you logged in as.
> You can replace the . with the word users or with the word everyone if
> you wish.
>

The root of drive letters, tends to have permissions
suited to stopping the writing of individual files.
Sometimes I'm prompted for "administrator" level permissions
via UAC.

For a user operating with a "limited" account, that account
doesn't offer administrator, and a UAC dialog probably will not
appear. If a person uses a limited account (not a member of
the administrator group), then their capabilities are
strictly limited and they're trapped in a shoebox.

I would expect your icacls command would work,
but at least for the file level of SID application
to the disk, getting to the root of the disk is a problem.

This is how you can make a short two-line script, to own stuff.

******* scripting takeown with itsmine.cmd *******
takeown /f %1 /r /d y
icacls %1 /grant administrators:F /t
******* end of itsmine.cmd *******

itsmine E: <=== don't do this to C:

https://social.technet.microsoft.com/forums/windowsserver/en-US/8299036a-3cfe-40d7-beb8-becd2e56c2f4/icacls-syntax-issues-with-backup-restore

icacls d:\ /save ntfsDdrive.txt /t /c # backup of permissions on D:

icacls d:\ /restore ntfsDdrive.txt # restoring permissions later

# file contents of top level of drive D: as ntfsDdrive.txt
Filename <=== this line is blank, needs to be changed to a single period "."
ACL
Filename
ACL

# Once the file has been edited, the top filename and ACL
# get applied to the root of the drive during restore.

So now, we can take a look at what a "typical" file looks like.
I select my backup drive letter on the Win10 machine (GPT partitioned).
I've placed a blank line between Filename/ACL line pairs, to improve
readability.

. <=== change this line to a dot, so the line below it applies to the root
D:(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;;0x1301bf;;;AU)(A;OICIIO;SDGXGWGR;;;AU)(A;;0x1200a9;;;BU)(A;OICIIO;GXGR;;;BU)

$RECYCLE.BIN
D:P(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;NP;0x1201ad;;;BU)S:AI(ML;OICIIO;NW;;;LW)

21154.avi <=== a long movie in AVI format, from analog tuner capture
D:P(A;OICI;FA;;;WD) <=== typical single file ownership

We can see the root of the drive,
has a metric ton of rubbish. We can compare this
in the lines in the Security tab of the drive properties,
to approximately line them up. To see how a person
might parse them. The icacls backup file is in roughly
the same order as the Security tab for the item.

Security tab, H:\
-------------------
D:(A;;FA;;;BA)
(A;OICIIO;GA;;;BA) Authenticated users
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY) SYSTEM
(A;;0x1301bf;;;AU)
(A;OICIIO;SDGXGWGR;;;AU) Administrator
(A;;0x1200a9;;;BU)
(A;OICIIO;GXGR;;;BU) Users

Now, that's on my H: drive. On the C: drive, in addition
to features like that, there is MIC (Manditory Integrity Control).
And a third-party utility like "micenum" can show the
overlay applied for security purposes on C: . Nobody knows MIC
is there, until weird stuff starts happening.

You can use backups of the security info, to see if
the commands you're issuing have an effect or not. And
by editing the first line of the "whole drive" backup
of permissions, you can then restore the entire drive,
including the root permissions. But only if the
Command Prompt window is owned by Administrator, would
a reapplication work.

The utility icacls will apologize for each entry it
cannot modify. I've never been able to "smash" anything
worth smashing, so can't say there are really good methods
for getting your own way. There may be a certain order
of doing things on the root of the drive, to achieve
a "result". You are not supposed to attempt to own
all of C: and messing around with a data-only partition
should be a lot safer. I tried an experiment the other
day that "should have worked but didn't" and had to
restore from backup. A person should take precautions,
and especially in my case, as I'm just not good with
permissions :-)

Summary: You can run icacls and do a Save, to record permissions
for later. After issuing some commands, you can do a
second run of icacls and do a Save, only change the output
filename. Then, compare the two text files, to see if
your issuance of commands, is making a difference or not.

Paul

Thanks.

I wouldn't say I really properly understand Windows permissions. I was
originally taught this type of stuff only on Unix which seemed much more
straightforward.

However I tend to try and give extra drives (not my C: drive) full
permissions for either everybody (for USB drives) or all users and
administrators for drives built in the the PC. But it's typically very
much a trial an error process every time I do it, because I don't need
to do it very often.

Maybe the OP is using a drive that was originally a C: drive in an old
PC that has only been erased rather than reformatted?

--
Brian Gregory (in England).

Brian Gregory wrote:
> Thanks.
>
> I wouldn't say I really properly understand Windows permissions. I was
> originally taught this type of stuff only on Unix which seemed much more
> straightforward.
>
> However I tend to try and give extra drives (not my C: drive) full
> permissions for either everybody (for USB drives) or all users and
> administrators for drives built in the the PC. But it's typically very
> much a trial an error process every time I do it, because I don't need
> to do it very often.
>
> Maybe the OP is using a drive that was originally a C: drive in an old
> PC that has only been erased rather than reformatted?
>

I've tried on occasion, to work out the permission
model, like break inheritance from an upper level,
so that I could take control of a lower level.

And all those experiments failed, big time.

I don't know who the intended audience of that
permission structure is. I presume, just the developer,
and the tech writer who writes articles about it.

When a person is a member of administrator group, there is
a possibility of an implicit Takeown happening in File
Explorer (the green bar appears, if you try to traverse
a user folder on a foreign C: partition). I usually
don't spend the time trying to manually coerce stuff,
because it seldom (if ever) works. After an implicit
Takeown happens, you might see the extra lines that
have been added to icacls output.

As you say, the model in Unix/Linux allows first time
success, which is a great confidence builder. I've
never had that feeling of first time success on Windows.

The opacity of the model is also a problem for security,
as when people "do stuff" to their OS, hardly anyone
ever expresses concern about how they've wedged the
permissions. It's one thing for some of the crowd
to "try to make Win98 out of it". But quite another
for people to have no concern at all about permissions
after they've made changes. I doubt anyone here
regularly uses icacls to pave stuff. Including me!
This suggests to me, that making the model "thick
and incomprehensible", has consequences.

Paul