There's an OS you might like. It has no UAC, no file permissions, no sudo nor chmod, as it has no multi-user support, no antivirus and no firewall, no protection rings, not even spectre/meltdown mitigations, and most of all - no guard-rails whatsoever: You can patch the kernel directly at runtime and it won't even give you a warn. And yet, it is perfectly safe to run. It's called TempleOS and it achieves such a flawless security by having no networking support whatsoever and barely any support for removable media. If you want a piece a software - you just code it in, manually. You don't have to check the code for backdoors if it's entirely written by you... only for CIA at your actual back door...

What does 'modems in mobile phones' mean? Isn't the whole thing a modem strapped onto a screen? What am I missing?

I'm a sysadmin and I work with Windows a lot.

The short version is that only the users granted permission to a given set of files can access those files. With NTFS permissions it's... Complicated. You can have explicit permission to a file, or implied permission via a group that you're a part of, or some combination of those things. You can also have read, but no write. You can have append but not create, you can have delete, but not list. It's a lot of very granular, very crazy permissions.

There's also deny permissions which overrule everything.

What has likely happened is that the posters user account doesn't have implied or explicit permission to the file, but if you sign in as an administrator, even if the administrator doesn't have permission to read/write/append/delete the file, the administrator has permission to take ownership of a file, and as owner, change the permissions of a file. Being owner doesn't mean you can open/read/write/append/delete anything, you can just change permissions and give yourself (or anyone else) permissions to the file.

Changing ownership is a right which, as far as I'm aware, cannot be revoked from admin level users. They can always change ownership. Owners of files cannot be denied the right to change the permissions of a file as far as I know. This will always result in some method by which administrative level accounts can recover access to files and folders.

In my experience, exceptions exist but are extremely rare (usually to do with kernel level stuff, and/or lockouts by security/AV software).

The poster might legally and physically own the device and all the data contained therein, and may have an administrative level account on that device, but the fact is, their NTFS permissions are not set to allow them access to the data. The post they're replying to is trying to let them know how to fix it by using an administrative level account and they're not tech-savvy enough to follow along.

I don't blame them. File permissions issues are challenging even for me, and I fully understand the problem.

I think what happened here is that something went wrong and messed up the permissions of some of the users files. MS help suggested that he login as an administrator and reatore the intended permissions.

I don't work with Windows boxes, but see a similar situation come up often enough on Linux boxes. Typically, the cause is that the user elevated to root (e.g. the administrator account) and did something that probably should have been done from their normal account. Now, root owns some user files and things are a big mess until you go back to root and restore the permissions.

It use to be that this type of thing was not an issue on single user machines, because the one user had full privileges. The industry has since settled on a model of a single user nachine where the user typically has limited privileges, but can elevate when needed. This protects against a lot of ways a user can accidentally destroy their system.

Having said that, my understanding of Windows is that in a typical single user setup, you can elevate a single program to admin privileges by right clicking and selecting "run as administrator", so the advice to login as an administrator may not have been nessasary.