# os x permissions and root/user chown



## am3av (Dec 23, 2010)

i have os x on the white macbook 7.1? the permissions for the group is really scaring me because, i ran disk repair and it said user should be 0, user is 80. so i reinstalled because i couldn't get it to fix and i know nothing about darwin, although i know a little bit about unix. anyhow, i ran after the install completed and it prepared the same log entries with the error reading user is 0, should be 80. i haven't been able to fix it over a week or two and i've asked in os x forums with no answers. i run the permissions repair tool once or twice a week though, i always estalbish a maintenance habit with available tools. now it is reading permission is 0 should be 95. all of these permissions are user. i assume this is an ownership thing, but taking ownership over files has had no luck as per this:

i enabled root so i could get a look at os x, and wanted to delete the old admin account made during install. that account wasn't signed in because i restarted and brought up efi, trying to issue a delete command and then i logged in as root and tried but still no dice either in deleting the account from terminal or chowning it and trying with the accounts preference pane. can i have only the root account on os x? tia.


----------



## Headrush (Feb 9, 2005)

We need more details.

What files are you specifically concerned with that have the wrong permission?

What group are you worried about, administrators?

Not sure what you mean by you brought up EFI and tried to issue delete. (EFI as in Openfirmware screen?)

You said you enabled root? (You became root using terminal?)

What do you mean by *delete* command?


----------



## am3av (Dec 23, 2010)

alright, i knew that:

to try and delete the installation created user after enabling root, I used the dscl . -delete /Users/username. and yes i mean i installed refit (because i couldn't get o+c+p+r or any kind of efi shell without doing so, and this was the only answer i could find on the net or in forums, a lot of forums seem pretty dead). refit is pretty easy to use though, so i was happy to see that provided a nice interface to interact with the firmware. obviously in the efi terminal the command just returned an error. likewise, i tried to chown the installation account through root with chown -Rf root:root (which is shortusername:usergroup and i'm unsure if i got this portion correct but it didn't prompt any errors except that it said the command didn't exist) /Users/username. Since this format kept failing i tried a traditional unix syntax which was chown root /users/username and this led to the next line on the prompt; in linux this can just as easily mean that the command was successful with no terminal customization but it didn't do anything for deleting the installation created account.

to enable root I used the accounts in preference pane, then the join button, the edit menu, enable root account.

the permissions which seem to change are 99% java related and are mostly in system and library. i can't see the entire name of the files, in the permission repair window they get cut off by elipses, is there a log file of this repair? the group 0 i am thinking is root. the 80 group might be wheel, i'm unsure how it works on os x unix, and i have no idea what group 95 might be unless it's a created user account. but whether or not root is enabled the groups may be 0,80, or 95 and this seems to change without me doing anything.

it's not really a worry, it's just that i got this in a refurbished state i think, and being that anti virus doesn't return anything (sophos), the permissions will not repair either from root, the disc, or within another accoutn login but will only continue to produce the error on running the repair tool;etc. my concern was made into an eeprom issue by another user. basically he/she told me that the eeprom carries the firmware which will attempt to boot with or without an os. it's the program that makes the little folder with a question mark in such cases. as such, i'm thinking i may need to flash and manually reload the eeprom and the concern there is that, i have no idea how I would manage that. i can't even seem to buy a proper torx for this motherboard let alone find a safe ultraviolet light to flash the eeprom which was the suggestion (i wouldn't try it without thorough knowledge of course).

that's all the details i have unless someone might tell me where the repair from disk utility is saving a log file of it's attempt to repair.


----------



## Headrush (Feb 9, 2005)

I'm not sure what to say to all of that, it seems its all over the place.

Frankly it sounds like you've probably caused just as many issues by messing around in the command line.

For starters, there is no root group. Group 0 is called the wheel group and user root is a member of that group.
Group 80 is the admin group and user root is a member of that group also.
Group 95 is related to a system process that deals with sharing.

You said you reinstalled and than later tried to enable admin account.
Why not re-install and add the admin account first. Then once booted into OS X add the user accounts. (using the GUI, not command line options.)

Not sure what you are talking about with the eeprom. Macs have a firmware that can be updated but its simply a program freely available from Apple that you double click and run. When you reboot it updates the firmware automatically.

Can you find out exactly what Mac model you have? What version of OS X are you running?

P.S. Are you trying to dual/triple boot other OSes too? If not you shouldn't have to use rEFIT. Most users should never need to get to the EFI command line to run any commands.

P.S. 2 Those permissions errors happen all the time especially with java and you shouldn't worry about them. AT the very least let Disk Utility repair them, don't try it manually.

P.S. 3 The application at /Applications/Utilities/Console will let you look at all the log files.


----------



## am3av (Dec 23, 2010)

O.K.;

Yes!, I am going to triple boot with Mac OS X, Windows 7, and either a compiled Linux Distro or BT4 (the copy of Helix I downloaded was prepacked with some Windows malware!). That is precisely why I installed rEFIt.

Secondly, after a software update, my OS X version is 10.6.4 and the MacBook is a white MacBook 7.1 edition. 

As far as your comment on the Mac firmware, I've only seen a clickable frontend to the firmware once, and it was on another Mac when a firmware update was available. I don't entirely see how EEPROM and the presence of firmware should clash though, my line of thinking is that in the absence of a BIOS/CMOS, a static EEPROM would be the only way to maintain a persistent boot handler, but I'm a newb. In fact, I thought CMOS was an EEPROM, and that firmware was utilized anytime an EEPROM was to be implemented, or any other hardware which linked one integrated circuit to another, while a driver specified handler information to a specific piece of hardware. Then in the rightful fashion of out-of-sight-out-of-mind, I promptly forgot the assignment of an EEPROM as responsible for any damned thing and as such, had an aha! moment when I was originally told that the cause for alt booting laid with EEPROM.

I knew that 0 was wheel, I call it root because it's the permissable group, if you're not in it you're not doing as much, thanks for the information on the 80 and 95 groups! I had absolutely no clue whatsoever.

So yeah, there is the simple information you requested, but it might help to know this:

The triple boot we were talking about requires Windows be installed, then OS X, then Linux. I put Windows on the internal disk, rEFIt is on an external disk. I plan to put both OS X & Linux on there as well. I figured out that putting rEFIt, in terms of having a manicured system, was a bad idea because I now have to boot with alt since Windows has been placed on the internal drive. I had to before anyway because OS X was on an external drive, but the tricky part is that now Windows is as stated, installed, the rEFIt menu does not show up. I'm thinking it should be alright, if I install Mac OS X then I can reinstall rEFIt and specify the internal drive which should altogether eliminate the need to use the alt boot method. I'll have to see about that, but I wanted to mention these things, in case it was going to be necessary to know. I'm sure it is. In fact, just to add a little side note, I do not understand how Windows was able to boot from the MacBook at all being installed onto an internal drive with rEFIt on an external drive. Therein, I'm confused as to the necessity and usefulness of rEFIt now.

I thought I had mentioned, Disk Utility will not repair the permissions. It will go through the farce s-t-s, and state either repair complete, or ... I think it said, you know I don't remember the exact message but the end result was, will not repair. That part I remember it created that wtf?! feeling.. And, again I tried this with both the Disk Utility while logged in, and then booted from the installation media.

I should've known console messages would be the answer to reading log files! It's Mac's Events Viewer I guess. Then, lastly, I don't know how to enable root during an OS X installation, nor a Windows installation and as such I've always had to suffer the automatic installer and then issue the terminal command in Windows & use the preference pane in OS X. If you could pass on that knowledge, that'd be awesome! I did search for that answer on the web, and the only possibility that occurred to me in not finding any articles on enabling root during mac os x installation was, install Darwin, enable root, install Aqua, and substitute the commercial packages for a CentOS/RedHat-like OS X installation.


----------



## Headrush (Feb 9, 2005)

Ok, we need to back track.

Please state which OSes you want on the internal MacBook hard drive and which ones you want on the external hard drive.

A couple points in the meantime:

1) Forgot anything about EEPROM. I'm not exactly sure what you referring to and if you are just confusing this with the Mac's firmware, but either way you don' have to touch or mess with it to triple boot.

2) rEFIt has to be installed on a HFS volume. If you put Windows only on the internal HD and OS X on the external, what happens is when you boot you have to hold the "alt" key (you should be saying "option" key) and this brings the Mac's built in boot manager up. Then you have to choose the hard drive where rEFIt is installed and again hold "option" to get to it's boot menu to choose between the other two OSes.

3) If you must have Windows on the internal MacBook HD, you are probably best using the advanced method and installing rEFIt into the hidden EFI system partition on the internal HD. (instructions on rEFIt site)

4) When you install OS X the user created during the initial startup after installing is added to the Administrators group. You can use this account of if you feel safer making a regular account, once booted into OS X under this admin account you can create another regular user account. (Don't remove the administrator account though)

5) Disk Utility can't always fix all permissions problems since they are activate system files. To correct these boot off your OS X DVD and use Disk Utility from there to repair the permissions.

Hope that helps.


----------



## am3av (Dec 23, 2010)

well, thanks for the answers on rEFIt, permissions, and the root account. really this is all i was in search of to be honest. I found a tutorial on triple boot and feel safe to say i can perform that installation solo. besides that, i figured out that having os x on the external drive was not going to permit for a linux install, because without (maybe) refit on the internal drive, linuix can't even one find the cd drive after booting, which is completely wierd, and two find the kernel images on the disc it's burnt to. that being the case i reinstalled os x to the internal drive when i knocked out last night. and as for the permissions errors, os x just isn't going to repair them at all because i tried to perform repair using the disk utility front end, it doesn't even work from the os x compact disc. the permissions sound normal enough, but, they are dynamically changing which is kind of cool security wise, but it's implementation being unknown to me is just as much a vulnerability. so, thanks in the very least i know where the log files are and can now manage to sift through the important records on left by maintenance, but do you know where the important configuration files would be located?tia


----------

