Home
Posted By: artie505 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]
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.


(#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 wink

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?


(#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?


(#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.
I moved this post from Mac OS X 10.6. It is a good discussion of a general troubleshooting topic with general application to all versions of OS X and not just Snow Leopard. At the moment we do not have a specific forum to lodge this type of discussion in so The Lounge ended up as the default.


My 2 cent addition to the discussion

Four things occur to me in this discussion:
  1. Testing from another account is a troubleshooting technique endorsed and recommended by Apple.
  2. Everyone is going to have an account on their Mac with administrative privileges. That is a simple given and no "special" account needs to be created unless that administrative account is the one you normally log onto and are having the issue with. In which case testing with a standard account would be comparing pears to apples if not oranges to apples.
  3. If you normally boot into a standard account then the test account should be a standard account. Besides that you already have an administrative account if one is needed. Note: given the default user account has administrative privileges I would venture only a miniscule percentage of Mac users even have a standard account on their system.
  4. I can think of several situations where it would be convenient to have a "test" account pre-created because the issue might prevent or at least make creating another account difficult.
My personal choice is having a pre-created test account with the same privileges as the account I normally use. Since, like the vast majority of Mac users, I never log onto a standard account I have a test account with administrative privileges. On the other hand, if I normally used a standard account, I would create a third account as the test account and give it standard privileges.
Posted By: grelber Re: Test user accounts... Admin or Standard? - 09/07/09 04:12 PM
Just out of curiosity:
What is a test account? For that matter what is any "account"?
As far as I am aware, one's hardware and software are a complete and closed system; accounts don't enter into the equation at all.
Clearly I'm missing something. Quite possibly it's a question of semantics or OS X jargon about which "I know nothing" (to quote Sgt Schultz).
(You can tell I don't get out much.)
Posted By: jchuzi Re: Test user accounts... Admin or Standard? - 09/07/09 06:49 PM
An "account" is basically the home folder for a particular user. If you double-click your hard drive, inside the Users folder you'll see your home folder (has a house icon) and the name that you originally set up for yourself. OS X allows the existence of separate accounts for each user (if desired) so that each user can maintain his/her files, preferences, applications, etc. to his/her liking and also maintain privacy. Since each account is password protected, it can be accessed only by someone who knows the password (at least theoretically; a savvy user can get around this easily enough).

Another way to look at the accounts that exist on your computer is to open System Preferences>Accounts. You'll get a list. In view of your question, I'd bet that there is only one account there. If you have set the computer to automatically log into that account at startup, you'll never have to enter the password to get in and that's probably why you're not aware of its existence.

The value of having a test account is for troubleshooting. Say, for example, you are having a problem with Safari in your main account. If you log into a test account and the problem is gone, the cause lies in the home folder of your main account and might be a corrupted cache, preference file, or something else that resides in that home folder. Consequently, you would try to find the culprit by playing with only the data in the main account.

If, on the other hand, the problem occurs in the test account also, then the cause lies outside the main account and might be due to a directory error or something else that is accessed by the entire system. Consequently, troubleshooting will be different.
Originally Posted By: grelber
Just out of curiosity: What is a test account? For that matter what is any "account"? As far as I am aware, one's hardware and software are a complete and closed system; accounts don't enter into the equation at all.

Clearly I'm missing something. Quite possibly it's a question of semantics or OS X jargon about which "I know nothing" (to quote Sgt Schultz). (You can tell I don't get out much.)

If memory serves, user accounts were actually introduced in OS 9 (the world in which you are currently trapped, i assume).

So just go into Control Panels, open Multiple Users, turn on Multiple User Accounts and enjoy.

smirk
Posted By: grelber Re: Test user accounts... Admin or Standard? - 09/07/09 07:19 PM
Thanks, Jon & Hal.
Just as I thought — OS X stuff, and which of course why Jon's suggestions don't match up with anything on my system.
"Account" suggests a third party, but here clearly isn't.
I had long since forgotten Multiple Users, the forerunner of user accounts, which of course is set to 'off'.
Posted By: dkmarsh Re: Test user accounts... Admin or Standard? - 09/07/09 07:50 PM

Quote:
Since, like the vast majority of Mac users, I never log onto a standard account I have a test account with administrative privileges.

I am that odd duck whose system is configured partly to facilitate testing troubleshooting issues reported by other folks.

Hence, I have an OS X 10.4 volume which I use primarily to check for the presence, location and behavior of various files and features in 10.4, lest I give someone running that OS information based on my 10.5 installation that's incorrect for their system.

Likewise, though I run an administrator account normally, I have both administrator and standard test accounts. This makes it easy to see what sort of limitations a standard user experiences, relative to an administrator account, through actual experimentation—something that's downright impossible on an installation with no standard accounts.
I normally run as a non-admin user. I won't go into the reasons why that's a good idea (they've been elaborated elsewhere); I'll limit myself to saying that I do think it's a good idea and something we should encourage other users to do. At the very least, we should not be encouraging people to create new admin accounts without strong reason.

A test account is for testing things. Almost by definition, if you're testing, you don't know what's going to happen. Using an admin account for testing is like swallowing the potion to see if it's poisonous.

If what you're testing is whether something behaves differently for admin/non-admin accounts, you can do that by temporarily making your test account an admin. But you should only do that if the admin-nature of the user is an essential feature of the test, and you should set it back after running that test.

I actually keep three test accounts lying around. One is a normal user, one uses file vault, and one has parental controls. There is also Leopard's Guest account. None of these has admin privileges.

Don't overlook Leopard's guest account. Most quick tests can be done right there, with no fuss or bother. In fact, the fact that the account wipes itself after every use makes it ideal for testing, because it precludes interactions between the test you're doing today and the test you did last week, whose details you've probably already forgotten.
© FineTunedMac