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.
I feel like he has a machine that someone set up for him, and he can’t escalate permissions, because he’s on a basic user account.
The normal way this works on a single user machine is:
You try to do something that is restricted to admin
Windows puts up a modal dialogue box asking if you want to do it as admin
You click yes
You do it as admin
But in that case he can’t have locked himself out of a file, he can only be locked out of things Microsoft think you shouldn’t muck with unless you know what you’re doing
On that last part, theres a difference between elevating a file to admin, and being an admin in Windows.
In a lot of cases the ui is GREATLY simplified when not an admin, to the point where you might only have like 20% of all available options.
For the standard user?
Great!
Not when you’re messing around with permissions.
It’s why you ALWAYS log in as Admin when setting up a windows server.
Iirc you can’t even install tiles without actually being an admin, even if you have all logins.
From my experience with windows, your current guess is correct btw :D
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.
Yep, there’s actually quite a few more than what I mentioned, if you get into the advanced dialogs.
IMO, it’s unnecessarily complicated, but given that NTFS is used for network file sharing in large companies, I get why it’s so crazy. They probably demand those kinds of granular permissions.
I know Linux is a lot simpler. Just read/write/execute, and a single group, single owner, and a setting for “everyone else” kind of thing, which is generally sufficient for 90% of use cases.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
Is this real? Are people having to request permission changes on files by petitioning microsoft to change their permissions?
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.
So this guy is just bitching because he sudo installed something?
It’s not MS having to manage your folder permissions remotely?
I feel like he has a machine that someone set up for him, and he can’t escalate permissions, because he’s on a basic user account.
The normal way this works on a single user machine is:
But in that case he can’t have locked himself out of a file, he can only be locked out of things Microsoft think you shouldn’t muck with unless you know what you’re doing
On that last part, theres a difference between elevating a file to admin, and being an admin in Windows.
In a lot of cases the ui is GREATLY simplified when not an admin, to the point where you might only have like 20% of all available options.
For the standard user? Great! Not when you’re messing around with permissions.
It’s why you ALWAYS log in as Admin when setting up a windows server. Iirc you can’t even install tiles without actually being an admin, even if you have all logins.
From my experience with windows, your current guess is correct btw :D
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.
Huh, having separate append permission is interesting. i didn’t realize that was an option.
Yep, there’s actually quite a few more than what I mentioned, if you get into the advanced dialogs.
IMO, it’s unnecessarily complicated, but given that NTFS is used for network file sharing in large companies, I get why it’s so crazy. They probably demand those kinds of granular permissions.
I know Linux is a lot simpler. Just read/write/execute, and a single group, single owner, and a setting for “everyone else” kind of thing, which is generally sufficient for 90% of use cases.