Hi Neil, I have not been avoiding your questions, just time has not permitted me to answer as yet. I will get back with a more thorough answer to 'Permissions' in Snow Leopard when possible. Also I don't profess to be an expert on Permissions, I don't profess to be an expert in anything ;-)
When you start up a brand new Mac, or start up after an Erase and Install, you will be asked if you want to migrate. That is the preferred time to migrate from your old Mac or backup to your New Mac or New Hard Drive. I would prefer Adam to do A. To do and Erase & clean Install of SL & then let Migration Assistant run & migrate everything across, which will bring his User Account / Settings & Files across. With way B. You DELETE the OLD (wrong) Administrator Account BEFORE you transfer the data across from the backup drive. This way, when you then 'Repair Permissions', the User should (hopefully) have the correct permissions on his data. I have done it this way before and I'm fairly sure the UID was 501 … At least I did not experience any permission problems. But, I'm open to anyone disagreeing with this. Of course neither of these ways will be possible if Adam doesn't have a complete backup of his old drive! Cheers, Ronni On 19/05/2010, at 10:47 AM, Neil Houghton wrote: > Hi Ronni & Adam, > > I have been following this with interest – I have had to sort out permissions > problems in the past, I generally get there in the end, but I still find many > aspects of permissions confusing. > > > I am hoping that Ronni could clarify how one area works: > > > I can see how approach A works – this is basically just like taking home a > new computer and migrating the data over from the old computer. > > With approach B, however how does the UID get back in sync – or does OSX work > around that? > > To elaborate on my query: > > It sounds like the old computer was set up with just the primary user > account, which would have had the default UID of 501 for the main account – > this is the account now on the back-up disk that we want to restore. > The technician set-up one main account on the new HD – which is therefore > also UID 501 – but with other details wrong (as per Adam’s id printout: >>> admins-imac:~ adam3$ id >>> uid=501(adam3) .............. > If Adam creates a NEW Administrator Account with exact details of the User > Account that he has on the backup drive it will presumably get a UID of 502 > (501 is already taken) - so the exact details may be the same but the UID > will be different. > When Adam DELETES the OLD Account – he is deleting the account currently with > UID 501. > > > So this is where I am unclear as to how things proceed: > > Would deleting account UID 501 result in the new account getting its UID > re-assigned from 502 to 501? or > Would migrating over the OLD account UID 501 result in the new account > getting its UID re-assigned from 502 to 501? or > Would the new account retain the UID 502 but the migrated files get their > ownership modified to suit this? or > I’m missing the point, what happens is ........ > > If the (new) main account has UID 502, would there be any problems at the > next migration to a new computer (with main account UID 501)? > > > Ronni, I hope you don’t mind me jumping in with these questions – but I know > that many of us find permissions intricacies somewhat confusing. > > > I know I had big problems in the past when I set up a new computer with an > account that was ALMOST the same as the old one! (I can’t remember now > whether the short names were the same but the user names different, or > vice-versa, or names the same but UIDs different) - I remember it was a > painful process sorting it out. > > > Cheers > > > > Neil > > -- > Neil R. Houghton > Albany, Western Australia > Tel: +61 8 9841 6063 > Email: [email protected] > > > > on 19/5/10 9:30 AM, Ronda Brown at [email protected] wrote: > >> Hi Adam, >> >> On 18/05/2010, at 8:35 PM, Adam Lippiatt wrote: >> >>> Ronni >>> >>> Thanks for this. I did have a backup of the drive but unfortunately after >>> having the machine for more than a month I think the technician got >>> exasperated and just wanted to see the back of it. So, I got a new hard >>> drive which was, unfortuantely, a little noisier than the original and also >>> the install was done on a new user account which did not have the same name >>> as the old one. >>> >>> So, perhaps this is the source of the permissions problems. >> >> Definitely, for sure … You don't 'own' (have Permissions) of the files, >> another User does! As I explained in my previous email. >> >> A couple of things need clarifying Adam. >> 1. You say you DID have a backup of the old Hard Drive (User Accounts / >> Settings / Data) … do you still have that backup? >> >> 2. Did the Technician do the New Install and create a New (different) User >> on the new Hard Drive? >> If so, he would have / or should have told you that you needed to create a >> new Administrator Account with EXACTLY the 'same User Name & Short Name & >> Password' that your Original Drive (& backup) have. >> Then 'Log Out' of the 'Wrong Account' , 'Log In' to the New Account (you >> have created exactly as is on the backup drive) & under System Preferences >> DELETE the 'Wrong User Account'. >> ThenTransfer everything across from the firewire 'Backup' Drive. >> >> What to recommend you do now to sort the mess out??? >> A or B? >> >> A. Do a complete Erase of your Hard Drive and Clean Install of Snow Leopard. >> 1. Startup from the SL install disk, erase the hard drive with disk >> utility (on the Disc) . >> 2. Quit disk utility, and proceed with the install. >> 3. On the first reboot it will offer to migrate your data from a Time >> machine backup or an External Drive. Choose your External Drive and migrate >> from the backup you have. >> (i.e When your computer restarts with the clean install, DON'T create a >> User Account, let Migration Assistant transfer your User Account / Settings >> / Files from the External Backup Drive … ) >> >> >> B. Do 2 that I mentioned above: >> 1. Create a NEW Administrator Account with exact details of the User >> Account that you have on the backup drive >> 2. 'Log out' of the OLD Administrator (wrong) Account. >> 3. 'Log In' to the NEW Administrator Account >> 4. DELETE the OLD Account >> 5. Transfer your Data across from the Backup Drive. >> >> Cheers, >> Ronni >> >> >>> I did the id command and got the following: >>> >>> admins-imac:~ adam3$ id >>> uid=501(adam3) gid=20(staff) >>> groups=20(staff),101(com.apple.sharepoint.group.1),204(_developer),100(_lpoperator),98(_lpadmin),81(_appserveradm),80(admin),79(_appserverusr),61(localaccounts),12(everyone),401(com.apple.access_screensharing) >>> admins-imac:~ adam3$ >>> >>> Thanks for your help. >>> >>> Adam >>> >>> Begin forwarded message: >>> >>>> Hi Adam, >>>> >>>> On 17/05/2010, at 12:03 PM, Adam Lippiatt wrote: >>>> >>>>> Thanks Ronda >>>>> >>>>> I will look into that. Unfortunately when the hard drive died I had to do >>>>> a lot of manual shifting of things as the service people could only give >>>>> me a fresh install with the data sitting in folders on the desktop. As >>>>> time goes by I am getting through all of the little issues. >>>> >>>> Hmmm, this doesn't sound good to me. From reading above, I take it you did >>>> not have a 'Backup' of the Drive before it was corrupted? >>>> If the service people have just given you what they recovered from the >>>> corrupted drive … and you are trying to copy these files onto the fresh >>>> install, there could be corruption in some of the files. >>>> >>>> Did you create an 'exact' User Account on the Fresh Install as the 'User' >>>> you had on the original hard drive? >>>> If you didn't, you will run into Permission problems, as you will find the >>>> UID & GID are not the same. >>>> >>>> Mac OS X displays the user name of the account that owns a folder or file, >>>> it’s easy to assume that that account with that user name owns the item. >>>> In reality, it’s not quite so simple. >>>> The owner is actually determined by a number called the UID—the user >>>> identification number, not by the user name. >>>> In addition the group is, in fact, determined by the GID—the group >>>> identification number. >>>> >>>> To reveal your account’s UID and primary GID, type id in a Terminal window >>>> (and then press Return). >>>> The output of the id command looks like this: >>>> ronni$ id >>>> uid=501(ronni) gid=20(staff) >>>> groups=20(staff),204(_developer),100(_lpoperator),98(_lpadmin),81(_appserveradm),80(admin),79(_appserverusr),61(localaccounts),12(everyone),401(com.apple.access_screensharing) >>> >>> -- The WA Macintosh User Group Mailing List -- Archives - <http://www.wamug.org.au/mailinglist/archives.shtml> Guidelines - <http://www.wamug.org.au/mailinglist/guidelines.shtml> Unsubscribe - <mailto:[email protected]>
