Skip navigation
This discussion is archived

Unable to make any user Administrator, seemingly...

11208 Views 6 Replies Latest reply: Mar 25, 2008 6:50 AM by Nielsomat RSS
quarterwit Calculating status...
Currently Being Moderated
Mar 19, 2008 4:39 AM
Hi,

Like many others, I have been through the "loss of Administrator status" fiasco on upgrading to Leopard. I have been through all the processes people have talked about and have ended up in the following state:

Logged in as myself, I am not admin. Mail does not recognise me and wants to set up new accounts; Journler (a third party app for note-taking) won't accept the password I use for it; and apps such as Time Machine will not accept my details.

I can log in as root. The usual advice recommended at this stage is to go to the Accounts preference pane and check "Allow user to administer this computer".

However, after checking this box, I can't save the change; either switching to another account and back or trying to close the lock result in the checkbox unchecking itself!

All the accounts, thus, are standard, and I can't change them.

What I want, of course, is an admin account that works (ie, a way to make the checkbox changes stick), and my Mail to recognise me, and Journler to recognise me. (I assume all these things are related.)

I'd be very grateful for any help!

Lawrence xx
MacBook G4, Mac OS X (10.5)
  • Robert Newall Level 3 Level 3 (605 points)
    Unry,
    Can you confirm that , whilst logged in as root, the account you then selected for the 'tick box' treatment was the errant admin? There have been some cases where the 'via root' fix has not been operable for various reasons but it worked for me.
    Unry, I hope you have also a reserve admin albeit not able to administer at present and have non admins to browse through etc. That is a secure scheme.
    If you have several users suggest you try the 'root route' to give admin rights to another user. You can always remove admin rights later. That way you could see if your inability was specific to a particular account.
    powerbook G4, Mac OS X (10.5.2), 1GbRam
  • Nielsomat Level 1 Level 1 (10 points)
    (skip to "** QUICKQUICK **" if you don't have much time)

    So I cancelled sleep last night after having lost administrator access as well. Basically what happened is that Azureus went apeshit and started filling up my whole hard disk whilst being unkillable. In the end I just held down the power button to shut the machine down. A reboot later all administrator users were gone.

    I went into single user mode to enable the root user, logged into it and tried to give administrator rights back through System Preferences. To no avail! Exact same problem as unry described in his initial post.

    I played around with dscl a while and when trying to add my user to the admin group I got the eDSUnknownNodeName as well. My hatred for Mac OS X grew a lot in these hours but I'm proud to say that human > machine. In my case what happened is that OS X fu**ed up big time and got itself into a position from which it couldn't recover on its own.

    Bit of background regarding dscl: Information about e.g. user groups and user accounts are stored in directories by OS X as opposed to e.g. /etc/passwd and /etc/groups on standard Linux systems. Now I'm certainly no guru in this area but OS X can interface with various "providers" for these directories. Typically this would be a LDAP or AD server. If you find yourself in such a setup the following might not necessarily help you, sorry In my case however I simply had a stand alone macbook meaning that my directory information is stored in /var/db/dslocal. In there are the XML files the command line utilities such as dscl interact with.


    ** QUICKQUICK **

    Armoured with that knowledge let's venture into single user mode once more:
    - Reboot
    - Hold Apple+S
    $ /sbin/fsck -fy
    $ /sbin/mount -uw /
    $ launchctl load /System/Library/LaunchDaemons/com.apple.DirectoryServices.plist
    $ dscl . append /groups/admin GroupMembership myuser
    => <dscl_cmd> DS Error: -14009 (eDSUnknownNodeName)
    - huh?
    $ dscl . ls /groups
    => long list with groups like "wheel" and "staff" but NO "admin"
    - Apparently this group got lost somehwo. ***** but shouldn't be a big problem, we'll just recreate it with its standard id 80. For this we use a convenient utility built on top of dscl
    $ dseditgroup -o create -i 80 admin
    => ERROR: A Directory Service error occured.
    14135: eDSRecordAlreadyExists
    - ***? It's there after all? Probably corrupted though? Let's delete and recreate it..
    $ dseditgroup -o delete admin
    => ERROR: A Directory Service error occured.
    14136: eDSRecordNotFound
    - Oh, COME ON! create command complains that this group already exists, delete command complains that it does infact not exist? We have to step down a level and dig into the actual storage for this stuff:
    $ cat /var/db/dslocal/nodes/Default/groups/admin.plist
    =>
    - empty output? Aaaahh! This is the key to the whole ordeal: the group definition file exists but is empty! So on the one hand directory service thinks the group exists and thus refuses to create it but on the other hand there is no information in this file, thus users can't be added, the group is not listed when using dscl etc.
    $ rm /var/db/dslocal/nodes/Default/groups/admin.plist
    $ dseditgroup -o create -i 80 admin
    $ dscl . append /groups/admin GroupMembership myuser
    - While you are in there take a quick peek into the other group definition files, if one is corrupted others might as well be..
    $ reboot

    Done.

    It might have been an edge case with me but I'm willing to bet that this fix, or a variation of it, can help several people out who reported similar problems. Personally I am very taken aback by this. Yes, Leopard is shiny but if an essential service such as Directory Service gets corrupted so quickly (unorderly shutdown) and can't automatically revocer from something as trivial as an empty group definition file, then I don't even dare to think about how much trouble a similarly poorly implemented FileVault might cause me..

    (e.g. IMHO the group.plist should never be just opened and written to. A copy should be created, this can then be edited and upon successfully writing this copy the group.plist and group.plist.tmp can then be switched to avoid ending up with an empty file..)

    In any case, hope it helps. Sorry for this rather long post I just was too proud..

    Cheers,
    Niels
    black Macbook, end of '07, Mac OS X (10.5.2)
  • Nielsomat Level 1 Level 1 (10 points)
    Hi Lawrence!

    I'm glad the previous solution worked for you. To get rid of your ghost user, without having tested it, the following should do the trick:

    user=YOURUSER
    for group in `id -G -n $user`; do
    sudo dscl . delete /groups/$group GroupMembership $user
    done
    sudo dscl . delete /groups/$user
    sudo dscl . delete /users/$user
    sudo rm -r /Users/$user

    You have to replace YOURUSER with the short login name of the user you want to delete.

    The following loop removes it from all groups it might be a member of, then we delete a group with the same name as the user (SKIP THIS STEP if your user is named "admin" or "staff" or something to that regard. You can check if there are other users in this group by calling dscl . read /groups/$user GroupMembership).

    Then we delete the user itself and finally its home directory. You might have a slightly different directory structure so check where your home directories are by e.g. calling "pwd" in your Terminal and modify the /Users/ prefix if needed.

    Good Luck
    Niels.
    black Macbook, end of '07, Mac OS X (10.5.2)

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.