Test user accounts... Admin or Standard? - 09/07/09 11:25 AM
The following discussion about one of our most frequently recommended troubleshooting techniques is buried in a PDF thread, and its lack of exposure has either prevented it from reaching its logical conclusion or prevented that conclusion from reaching the FTM troubled/troubleshooting public...
(#1852)
[Re: roger]
(#1870)
You may always make that recommendation; I don't.
What's your reasoning?
(#1878)
You may always make that recommendation; I don't.
What's your reasoning?
Narrowing the scope of the problem of course
After trying "quick fixes", generally the second step is to gather information about a problem. One good thing to know is the general scope of the problem. Knowing if a problem affects just a single user or affects all users generally divides the root of the problem down to user account files (cache etc) or system problems. In most cases, a fix for one does not work for the other, so you can cut your problem solving roughly in half without any additional information.
And it's always a good idea to have a second "emergency" admin account available in case your main account develops a problem that prevents you from logging in.
Of course there is a third group of problem space, hardware vs software, but that is most easily tested by booting the suspect machine's hard drive off another mac, but not everyone has another mac they can use for this. "Hardware, System, User" make up the three primary problem spaces.
And for the record of course, that fourth problem space lovingly referred to as "pebkac". Failing to consider that one can waste a lot of your time.
(#1880)
(#1882)
No, what I really meant is that in the absence of a specific reason to make it an administrator account, why should one do that?
I understand that having a second administrator account is a good idea in general, but why is it a good idea for troubleshooting? What if the user normally runs a standard account? Wouldn't it make more sense to test for account-specific vs. system-wide symptoms in that case by logging into another standard account?
(#1909)
(#1922)
Well, suppose the problem is a permissions issue: the user is trying to do something for which a standard account doesn't have access. Trying to do the same thing in a test administrator account will yield no problem. Hence, the user—following the black and white reasoning so often employed here—will conclude that there's something wrong with his or her regular (standard) account, and trash a bunch of plists or cache files—as per our frequent urging—and, ultimately (since those approaches won't work), create a new user or reinstall the OS.
Logging into a test standard account, OTOH, would reveal that the problem is not unique to the regular account.
(#2233)
(#1852)
[Re: roger]
Originally Posted By: artie505
> if you don't have another USer account, you can make one (it's good to have for testing things just such as this!) in your Account preferences in the System Preferences.
We always recommend that posters creating test user accounts check the "Allow user to administer this computer" box, roger.
We always recommend that posters creating test user accounts check the "Allow user to administer this computer" box, roger.
(#1870)
Originally Posted By: dkmarsh
You may always make that recommendation; I don't.
What's your reasoning?
(#1878)
Originally Posted By: Virtual1
Originally Posted By: dkmarsh
You may always make that recommendation; I don't.
What's your reasoning?
Narrowing the scope of the problem of course
After trying "quick fixes", generally the second step is to gather information about a problem. One good thing to know is the general scope of the problem. Knowing if a problem affects just a single user or affects all users generally divides the root of the problem down to user account files (cache etc) or system problems. In most cases, a fix for one does not work for the other, so you can cut your problem solving roughly in half without any additional information.
And it's always a good idea to have a second "emergency" admin account available in case your main account develops a problem that prevents you from logging in.
Of course there is a third group of problem space, hardware vs software, but that is most easily tested by booting the suspect machine's hard drive off another mac, but not everyone has another mac they can use for this. "Hardware, System, User" make up the three primary problem spaces.
And for the record of course, that fourth problem space lovingly referred to as "pebkac". Failing to consider that one can waste a lot of your time.
(#1880)
Originally Posted By: jchuzi
I think that dk meant that the test account should be a standard account rather than administrator (artie specified administrator). I'd like to see your take on this as well as artie's and dk's. My thought is that an administrator account gives you easy access to all applications so it should be simpler to see if the problem is account-specific.
Other thoughts please?
Other thoughts please?
(#1882)
Originally Posted By: dkmarsh
Quote:
I think that dk meant that the test account should be a standard account rather than administrator...
No, what I really meant is that in the absence of a specific reason to make it an administrator account, why should one do that?
I understand that having a second administrator account is a good idea in general, but why is it a good idea for troubleshooting? What if the user normally runs a standard account? Wouldn't it make more sense to test for account-specific vs. system-wide symptoms in that case by logging into another standard account?
(#1909)
Originally Posted By: artie505
> No, what I really meant is that in the absence of a specific reason to make it an administrator account, why should one do that?
I understand that having a second administrator account is a good idea in general, but why is it a good idea for troubleshooting?
Truth be told, I can't think of any particular troubleshooting benefit(s) to be gained by giving one's test account Admin status.
My reasoning (which is akin to V1's "And it's always a good idea to have a second "emergency" admin account available in case your main account develops a problem that prevents you from logging in.") is that there are times when something that requires authentication needs to be done right now, no time for head-scratching or waiting for responses to a post, and having a test account with Admin status kills two birds with one stone in such instances.
> What if the user normally runs a standard account? Wouldn't it make more sense to test for account-specific vs. system-wide symptoms in that case by logging into another standard account?
Interesting thought; perhaps a user who normally runs a Standard account ought to have two test accounts, one Admin and one Standard.
But which troubleshooting aspect(s) of the test account do you envision as being compromised or lost when it is Admin and the account with the issue(s) is Standard?
I understand that having a second administrator account is a good idea in general, but why is it a good idea for troubleshooting?
Truth be told, I can't think of any particular troubleshooting benefit(s) to be gained by giving one's test account Admin status.
My reasoning (which is akin to V1's "And it's always a good idea to have a second "emergency" admin account available in case your main account develops a problem that prevents you from logging in.") is that there are times when something that requires authentication needs to be done right now, no time for head-scratching or waiting for responses to a post, and having a test account with Admin status kills two birds with one stone in such instances.
> What if the user normally runs a standard account? Wouldn't it make more sense to test for account-specific vs. system-wide symptoms in that case by logging into another standard account?
Interesting thought; perhaps a user who normally runs a Standard account ought to have two test accounts, one Admin and one Standard.
But which troubleshooting aspect(s) of the test account do you envision as being compromised or lost when it is Admin and the account with the issue(s) is Standard?
(#1922)
Originally Posted By: dkmarsh
Quote:
But which troubleshooting aspect(s) of the test account do you envision as being compromised or lost when it is Admin and the account with the issue(s) is Standard?
Well, suppose the problem is a permissions issue: the user is trying to do something for which a standard account doesn't have access. Trying to do the same thing in a test administrator account will yield no problem. Hence, the user—following the black and white reasoning so often employed here—will conclude that there's something wrong with his or her regular (standard) account, and trash a bunch of plists or cache files—as per our frequent urging—and, ultimately (since those approaches won't work), create a new user or reinstall the OS.
Logging into a test standard account, OTOH, would reveal that the problem is not unique to the regular account.
(#2233)
Originally Posted By: artie505
I almost forgot about this line of discussion what with its being buried in the middle of a PDF thread.
> Well, suppose the problem is a permissions issue: the user is trying to do something for which a standard account doesn't have access. Trying to do the same thing in a test administrator account will yield no problem. Hence, the user—following the black and white reasoning so often employed here—will conclude that there's something wrong with his or her regular (standard) account, and trash a bunch of plists or cache files—as per our frequent urging—and, ultimately (since those approaches won't work), create a new user or reinstall the OS.
Logging into a test standard account, OTOH, would reveal that the problem is not unique to the regular account.
1. By that reasoning, when your hypothetical user logs in to a standard test account and runs into the same permissions problem se will conclude that se's got a systemic issue and just skip the plist and cache trashing and the creation of a new user and immediately reinstall OS X. (Your user is pretty narrowly focused, having as much troubleshooting knowledge as you give hir credit for while at the same time being unaware that a permissions issue has nothing to do with either plists or caches.)
2. Your scenario has actually established a troubleshooting purpose for creating one's test account as Admin... It can be used to establish that logging in to an account with elevated privileges overcomes a permissions issue in a standard account.
> Well, suppose the problem is a permissions issue: the user is trying to do something for which a standard account doesn't have access. Trying to do the same thing in a test administrator account will yield no problem. Hence, the user—following the black and white reasoning so often employed here—will conclude that there's something wrong with his or her regular (standard) account, and trash a bunch of plists or cache files—as per our frequent urging—and, ultimately (since those approaches won't work), create a new user or reinstall the OS.
Logging into a test standard account, OTOH, would reveal that the problem is not unique to the regular account.
1. By that reasoning, when your hypothetical user logs in to a standard test account and runs into the same permissions problem se will conclude that se's got a systemic issue and just skip the plist and cache trashing and the creation of a new user and immediately reinstall OS X. (Your user is pretty narrowly focused, having as much troubleshooting knowledge as you give hir credit for while at the same time being unaware that a permissions issue has nothing to do with either plists or caches.)
2. Your scenario has actually established a troubleshooting purpose for creating one's test account as Admin... It can be used to establish that logging in to an account with elevated privileges overcomes a permissions issue in a standard account.