Art Todesco wrote:
On 12/12/2018 10:38 AM, Art Todesco wrote:
On 12/12/2018 10:27 AM, J. P. Gilliver (John) wrote:
In message , Art Todesco
writes:
I think it was the latest MS rollout today. Everything on my
computer, both C: and D: have been made read only. And I can't seem
to fix it. I've tried to change permissions and it just goes through
and seems to change, however, the next time you access any folder or
file, it goes back to read only. Any ideas on how to get back to
normalcy?
AskWoody says "December 2018 Patch Tuesday is under way" and
"MS-DEFCON 2: Patch reliability is unclear. Unless you have an
immediate, pressing need to install a specific patch, don't do it."
If you're pretty convinced it _is_ the update (I see three - a .net
one, a system one, and the usual MSRT), have you tried a System Restore?
No I haven't ... will do that next. Also, I can't even change the
name of any file on my data drive, d:, as it complains, "Unknown
User"! What's that all about?
I did a System Restore to eliminate this morning's update and now, all
seems to be fine. Very weird. Of course, I haven't checked every
single file, etc., but the ones I had problems with after the update,
seem to be ok. Thanks for all the advise.
And that "test" helps eliminate a lot of things.
There is actually an "attribute" for the partition,
that can be set or cleared in DISKPART.
https://blogs.technet.microsoft.com/...ead-only-help/
Read-only problems *hardly ever* relate to a direct
security property. The odds of it being "just a tick
box in the Security Tab" are pretty poor. These problems
always seem to be the "obscure kind". The kind without
a simple viewer, to check for.
The permissions model in Windows is labyrinthine and I
still don't have a tool I'd give you to make it easier
to understand. Sysinternals "accessenum" is an example
of an attempt to display effective access rights, but it's
still a UI failure.
The issue is so bad, they need to write an "expert assistant"
program, rather than a simple "permission lister". You
should be able to click on a file, and an "expert assistant"
would tell you "you can't access this because of ACE or
ACLS or the Security Properties tab has the control needed
or some idiot applied a Deny to the entire disk or this
is caused by a partition attribute setting".
And the IT people who run Domains would be in "double the trouble"
trying to figure out what's wrong.
There are so many levels of security, some "explainer" sites
will write 12 to 20 pages of "explainer" materials, then end
with "there is this other subject I should include but
it would make the explanation too long" :-/ That's when
you know that understanding permissions, is a bottomless pit.
Even if I had you run "icacls" and generate a log, that does
*not* dump all the possible permissions. And if you ever look
at one of these files, it's plenty complicated enough, even
though it's only scratched the surface.
icacls d:\ /save ntfsDdrive.txt /t /c DErr.txt 2&1
Stuff would scroll down the screen, without the redirections on
the end. The "DErr.txt" has a list of errors when the
tool hits Junction Points it's not allowed to descend.
If you were completely denied access to a disk, then
obviously the program cannot enumerate things it cannot
read. This approach only "tells you half of what you need
to know" for "only some of the easy problems".
You can use "micenum" to display the overlay on the C:
drive that provides additional protection for Program Files
or System32 or the like. A problem came up where the
Manditory Integrity on somebodies C: drive seemed to be
wrong, but even with this, and trying to correct the
problem, it still couldn't be corrected. You would not
need this for the D: drive.
https://www.elevenpaths.com/labstool...num/index.html
It doesn't really take that much of a screwup to make
stuff totally inaccessible.
Paul