MacInTouch Amazon link...
Channels
Apple, Troubleshooting, Questions

Ric Ford

MacInTouch
I install the Mac first with all available/required Apple software updates using an admin account called "setup" (and then clone this if required for multiple computers). I then use Migration Assistant to bring across everything from the old computer (all accounts, all data, all applications). I then delete the "setup" account and tidy up/remove any applications/utilities as required.
That's probably fine in general, but if there were no "Setup" account on the original system, this would result in each of the original accounts getting a new, different UID on the new system from what they had previously (which may not matter in many cases).
 


Ric Ford

MacInTouch
I am hardly an expert in this, but I do know I don't do anything in upgrading or migration without doing clones first.

I have also done a brand new install and then moved over data files and had permission issues that caused me to use MacWorld's recommendations to fix them:
As you note, making a complete clone before doing any permissions/ownership operation is imperative. Why? Because there is no Undo!

I once made the very big mistake of selecting a top-level directory in the Finder and using Get Info to set ownership and permissions to my own user account, choosing the "Apply to Enclosed Items" option. Ooops! Among the hundreds of thousands of files in a Mac system are a great number that have special owners and permissions. And these are scattered throughout the system, making it impossible to fix errors manually among these hundreds of thousands of files. Did I mention that there's no Undo in the Finder for this operation? (Or that I hadn't made a clone just before making this mistake?) Not a good mistake to make...
 


As you note, making a complete clone before doing any permissions/ownership operation is imperative. Why? Because there is no Undo!
I once made the very big mistake of selecting a top level directory in the Finder and using Get Info to set ownership and permissions to my own user account, choosing the "Apply to Enclosed Items" option. Ooops! Among the hundreds of thousands of files in a Mac system are a great number that have special owners and permissions. And these are scattered throughout the system, making it impossible to fix errors manually among these hundreds of thousands of files. Did I mention that there's no Undo in the Finder for this operation? (Or that I hadn't made a clone just before making this mistake?) Not a good mistake to make...
I second, third and fourth the idea of making a clone - or a few clones - before doing upgrading, migrating or anything else, really.

I made that same mistake with changing permissions. Never again.

As for the general migration discussion, which I read in bed last night and could not reply to, it got me thinking. It would seem to not make a difference if you were to use Migration Assistant immediately - before first boot - or later, but my gut says differently. And maybe it's just my gut. I have done many dozens, if not hundreds of migrations, for myself and for clients. When Migration Assistant first appeared, it felt like a godsend - still does, actually. In the old days, I'd have to copy files individually, re-do settings individually, and reinstall software by hand. Migration Assistant made life easy.

There were times when I suspected it might be migrating an old problem along with the other stuff, but I'm not sure if that was ever really true. Anyway, it seems to me, based on experience and increasingly faulty memory, that I have had far fewer problems when migrating immediately, as part of the install process, than when I let it boot and do it later, even the next day. I just don't recall as many issues popping up when I do it that way.

And, yes, creating a new admin-level user can be a nightmare if you don't know what you're doing. In some cases, you could be left with a ghost user for years, just sitting there, if you're not careful. I am careful, but many people are not.

Anyway, I was just in another discussion where it seemed as though someone might be suggesting that system snapshots were being migrated. I'm not sure if that's what they were suggesting, but it seemed as though that was the only thing that made sense of their argument. Anyway, I'll shut up now.
 


My personal preference is to run Migration Assistant on a new machine before doing anything else. This is because on a past transfer, I did a functionality check first, and as others have discussed above, a UID mismatch was created. This created problems with my Keychain and with accessing historical Time Machine backups.

Since then (the above happened on an igloo iMac to Aluminum iMac transfer so it obviously was quite some time ago now), I haven't run into any difficulties doing function checks and updates after migrating.

your milage may vary, of course.
 


Ah, thanks for jogging my memory. That's indeed an issue. If you migrate during first boot, then the user accounts and UIDs will be identical to what was on the source Mac. If you do not, then it is all to easy to get:
  • duplicate user accounts - a mess that isn't necessarily easy to clean up
  • user accounts with identical names but different UIDs (affecting permissions)
  • various settings (system/security/cloud/network/etc.) may get changed
And, if you do anything significant whatsoever on the new system prior to migration, it can be a huge issue to synchronize changes (depending, of course, on exactly what was done).
I ran into exactly those problems after buying a new MacBook Air and making the mistake of updating it -- or letting it update itself -- before migrating users onto it. The user names got mixed up and duplicated, and after considerable fussing around I finally had to create a new admin user, kill the new Admin user I had created, erase the initial import of my Admin account from my desktop, re-import my Admin user account, and go through an annoying series of re-naming users.

It created a lot more work for me to get the Air to behave like I want it to on my household/home business network. So, at least in my case, migrating on the first boot would have saved a lot of time and trouble.
 


Just to add another data point:

I installed a 500GB Crucial MX500 SSD in my 2012 MacBook Pro 15" this weekend, using my usual method of transferring user data to new machines or hard drives. I started by cloning the original Hitachi 500GB drive off to an external backup drive before pulling it. I installed the SSD, formatted it, and installed High Sierra fresh from a bootable thumb drive I already had prepped. On first boot I ran Migration Assistant and migrated users, applications and data from the backup drive.

During the process, Migration Assistant told me that my fresh install of High Sierra on the SSD was older than the one installed on the backup drive (10.13.2 vs 10.13.6) and asked if I wanted to update it. I told it yes, and it downloaded the updater, ran it, and then continued the migration. It later gave me a similar error about iTunes, with similar results.

On completion, it finished booting into my normal desktop. So far everything is running normally (and somewhat faster). My particular experience with Migration Assistant was quite satisfactory, as has been every other experience with it so far.
 


As you note, making a complete clone before doing any permissions/ownership operation is imperative. Why? Because there is no Undo!
I once made the very big mistake of selecting a top-level directory in the Finder and using Get Info to set ownership and permissions to my own user account, choosing the "Apply to Enclosed Items" option. Did I mention that there's no Undo in the Finder for this operation? (Or that I hadn't made a clone just before making this mistake?) Not a good mistake to make...
Ric, your note reminded me that Apple could and probably should put up dialog warning to users that "There is no undo for the operation you are about to execute, so it would be wise to have a clone of your drive before you do it, just in case you need to revert!"
 


That's probably fine in general, but if there were no "Setup" account on the original system, this would result in each of the original accounts getting a new, different UID on the new system from what they had previously (which may not matter in most cases).
Ric, that's exactly right. It will certainly cause problems if a user has some private files on a second local volume. That could be an external drive or another internal drive.

Let's say your user name is Fred and you are the first user. If you "own" some files on a second disk, then the original system will describe them as owned by "Fred", but actually they are recorded as being owned by user 501. If you create a new system with a setup user and then migrate Fred's account, Fred will become user 502 on the new system. Migration Assistant fixes up everything on the new system, but it does not mess with the external volume (heaven forbid!). Thus, you (Fred) do not have access to "Fred's" files on the second volume without messing with permissions.

Graham's method works wonderfully if you've always done it that way, but if you change to it, you will have permissions problems with external drives. I wish this were not the case, as it greatly simplifies starting a system with FileVault, as Graham points out.
 


I bought a new iMac today (using the MacInTouch Amazon link :)
It says High Sierra is the OS, but I assume that it will be an early version. So, any reason not to copy the latest combo update onto a thumb drive and install it on the new machine before I migrate from the old one?
I have migrated once, and it was a no-brainer. So I think that running the combo, then migrating would be the simplest way to go.
Just to update... Somehow, when migrating, not all user info was transferred, resulting in an unholy mess. After hours of trying to recover, I simply migrated again, and it worked. However, the new user ID issue reared its head, so I have a few things to figure out and/or work around. On the other hand, the retina screen is amazing! Thanks to all for the help.
 


Ric Ford

MacInTouch
Graham's method works wonderfully if you've always done it that way, but if you change to it, you will have permissions problems with external drives. I wish this were not the case, as it greatly simplifies starting a system with FileVault, as Graham points out.
You should be able to pre-encrypt the new Mac/new drive with FileVault before starting installation/migration. If necessary (for an internal drive), mount the drive in Target Disk Mode. Also, be sure to format with a very small unencrypted partition, from which space will be taken for the Recovery partition.

After that, (re)install the new macOS on the new drive/Mac, which should remain encrypted*, and you can do the migration at first boot into the encrypted system.

*I once had the Apple installer decrypt an encrypted volume without warning during the installation/migration operation - this was in the OS X 10.10 timeframe, and I noted it on MacInTouch at the time. Tthat was an unusual occurrence, which shouldn't typically happen, but be careful to check that the volume remains encrypted (and make sure to have some unencrypted space for the Recovery partition creation).
 


You should be able to pre-encrypt the new Mac/new drive with FileVault before starting installation/migration. If necessary (for an internal drive), mount the drive in Target Disk Mode. Also, be sure to format with a very small unencrypted partition, from which space will be taken for the Recovery partition.

After that, (re)install the new macOS on the new drive/Mac, which should remain encrypted*, and you can do the migration at first boot into the encrypted system.

*I once had the Apple installer decrypt an encrypted volume without warning during the installation/migration operation - this was in the OS X 10.10 timeframe, and I noted it on MacInTouch at the time. Tthat was an unusual occurrence, which shouldn't typically happen, but be careful to check that the volume remains encrypted (and make sure to have some unencrypted space for the Recovery partition creation).
I did this, and now I have to enter the encryption password to boot up. I haven’t found any way to give admin or other users the ability to unlock the drive with their user passwords.
 


Ric Ford

MacInTouch
I did this, and now I have to enter the encryption password to boot up. I haven’t found any way to give admin or other users th ability to unlock the drive with their user passwords.
I think you can fix this via:

System Preferences > Security & Privacy > FileVault > Click the lock to make changes > [enter password] > Enable Users
 


Ric, that's exactly right. It will certainly cause problems if a user has some private files on a second local volume. That could be an external drive or another internal drive.

Let's say your user name is Fred and you are the first user. If you "own" some files on a second disk, then the original system will describe them as owned by "Fred", but actually they are recorded as being owned by user 501. If you create a new system with a setup user and then migrate Fred's account, Fred will become user 502 on the new system. Migration Assistant fixes up everything on the new system, but it does not mess with the external volume (heaven forbid!). Thus, you (Fred) do not have access to "Fred's" files on the second volume without messing with permissions.
Would a workaround for this situation be to:
  • in Finder, select the icon for the drive containing files with incorrect owners
  • select Get Info from the File menu
  • click the lock icon at the bottom of the Info pane
  • enter Admin password
  • click the box labeled "Ignore ownership on this volume"
Certainly the best approach would be to avoid this situation by doing migration using other tips posted here, but ignoring ownership might work around the issue.
 


That's probably fine in general, but if there were no "Setup" account on the original system, this would result in each of the original accounts getting a new, different UID on the new system from what they had previously (which may not matter in many cases).
After a fresh OS installation, I always create the same accounts in the same order, which has always resulted in the same UID. Then I migrate data. I guess if you had a lot of accounts on a computer, or the way UIDs were issued changed, that would fail, but I've always had success with it.
 


Just to update... Somehow, when migrating, not all user info was transferred, resulting in an unholy mess. After hours of trying to recover, I simply migrated again, and it worked. However, the new user ID issue reared its head, so I have a few things to figure out and/or work around. On the other hand, the retina screen is amazing! Thanks to all for the help.
And, I forgot - I was going to do the combo update after migration, but migration did the update automatically to bring the new system up to date with the old one. :)
 


OK, this is getting frustrating. Two things:
1) When I log in, I use my account, which is admin. But it seems I have no permissions by default - I have to authenticate everything, like trashing a file in my home directory, etc.; and
2) When I set a specific folder for downloads in Safari, it always reverts back to "Downloads" in my home directory.

?
 


I just helped a young college-age relative out by swapping the original hard drive in the 2012-era MacBook Pro for an SSD. Made a carbon copy backup on a spare drive (for safety/archive), swapped the drives, put his original hard disk drive in a cheap enclosure, and Carbon Copy Cloned the original onto the SSD. Restarted - everything perfect.

Upgraded Yosemite direct to High Sierra using the App Store - everything worked.

The computer is much, much faster (due to the SSD, of course).

CCC couldn't copy one file - nothing important, but I reckon the original hard disk drive is on its last legs. A surplus hard disk drive has been repurposed to service as Time Machine drive.

A cheap and excellent upgrade. No complaints, and kudos to Carbon Copy Cloner (just a satisfied customer).
 



OK, this is getting frustrating. Two things:
1) When I log in, I use my account, which is admin. But it seems I have no permissions by default - I have to authenticate everything, like trashing a file in my home directory, etc.; and
2) When I set a specific folder for downloads in Safari, it always reverts back to "Downloads" in my home directory. ?
Well, now, in General System Preferences, it shows where I asked it to download to (where previously it showed the wrong place), but it still actually downloads as in "2)" above.

And one more anomaly. In the Users directory, where accounts are listed, there is a weirdness. My account is actually "name 2", but the account shown as Home in the folder is "name 1 2". Whenever the system shows the account name - on the login screen for example - it shows it correctly as "name 2". Can I simply correct the account name in the folder without affecting the operation of the account?
 


I’d love to know what the SMART data reports for that drive.
Disk Utility shows 'verified.' SMART Reporter tests show 'failing' (looking at some of the details, scarily so, although I don't pretend to understand them). I don't see a figure for the number of failed sectors, but it's clear that my relative got lucky that I changed the drive before it was completely borked. There was also no backup whatsoever.
 


Disk Utility shows 'verified.' SMART Reporter tests show 'failing' (looking at some of the details, scarily so, although I don't pretend to understand them). I don't see a figure for the number of failed sectors, but it's clear that my relative got lucky that I changed the drive before it was completely borked. There was also no backup whatsoever.
I remain unconvinced that Smart Reporter is accurately predicting SSD failures. I had Crucial tell me that Smart Reporter is not accurate with SSDs - but maybe that is marketing/baloney. I do know that the Crucial SSD had problems as reported by both SoftRAID and Smart Reporter. Other times, Smart Reporter reported a prospective failure and SoftRAID did not. I updated its firmware more than a month ago. The Crucial SSD was restored into the mirrored array and has been working flawlessly according to SoftRAID. But Smart Reporter's brain is still stuck on the SSD is failing, and thus Smart Reporter is useless at reporting on the condition of the SSD after the firmware update. So how do I delete Smart Reporter's memory of past predictions?
 


Ric Ford

MacInTouch
I remain unconvinced that Smart Reporter is accurately predicting SSD failures....
As I've mentioned before, DriveDX seems to me to be a good utility for monitoring drive health and SMART data. It might be worth a look.

I'll also note again that there are discrepancies in how different vendors' devices report SMART data, with some reporting opposite numbers vs. others, so that can be challenging for utilities that report on the data.

SMART Utility actually has preference settings to accomodate some of these issues.
 


I agree completely - it's frustrating to have so little control over what gets migrated. Here's Apple's support document:
I've migrated from one Mac operating system to another using Migration Assistant many times, mostly because of laziness. And, in gereral, it's worked well.

For whatever reason, though, when I decided to upgrade both my Mac Pro and my MacBook Pro to Sierra, I decided to do it the hard way... and I was very pleasantly surprised with the results.

I started by backing up the crap out of both machines. Time Machine and two Carbon Copy Cloner clones each. Then I downloaded the Startup Disk Maker app and made a USB installer out of Sierra.

I also prepped by making sure I had a serial number stored for all of the software that I would need in 1Password, and I de-activated iTunes and all of the Adobe stuff.

I started with the Mac Pro. I booted into the recovery partition, and wiped the hard drive on the machine, writing zeros once to the whole drive. I think this exercises the drive and alerts the hard drive controller to any suspect sectors. One the drive was clean, I booted into the startup disk and installed Sierra on the newly cleaned machine. I set up a new account (which is guaranteed to be UID 501) and did all of the operating system updates.

As I did all of this, I kept a file that documented the whole procedure, which made things much easier on the laptop.

The first thing I installed was Dropbox, so that I'd have access to 1Password. Once I had 1Password installed and had access to my vault, I was able to put in the serial numbers of all of the rest of the software that I re-installed.

The software that I was most worried about was Apple Maii, specifically manually importing all of my old mail, but to my surprise, it worked flawlessly. iCloud made the migration of the calendar and notes easy.

In the end, there's something very satisfying about installing the operating system from absolute scratch, and then deciding what's important in terms of software on your system, re-downloading all of that so you know you have the absolute latest version, and only migrating the things that you really need. It's amazing how much crap builds up in your system that you really don't need.

Doing this from scratch isn't for everyone, but it was actually much less painful than I feared, and I was very satisfied with the result. I don't know if the system is any more stable because I started from scratch, but at least I don't have to wonder if that's a factor.
 


I remain unconvinced that Smart Reporter is accurately predicting SSD failures. I had Crucial tell me that Smart Reporter is not accurate with SSDs …
I notice that SmartReporter's developer also makes SSDReporter, whose web page states, “many 'Micron' and 'Crucial' SSDs are incompatible.” Detailed investigation is left as an exercise for the reader.
 


I remain unconvinced that Smart Reporter is accurately predicting SSD failures.
For clarity, the drive that I was referring to was an hard disk drive that was failing, not SSD - I have no position or info on whether it reports SMART data accurately for SSD's. I've found it to be useful for HDDs, but I don't use it for SSDs.

On the failing drive above, I dug a bit more, and it was reporting 254 reallocated sectors (which may be the maximum?). Other parameters seemed to flag problems as well.

At any rate, clear to me not worth risking any more data on that drive, given that it coincided with a corrupted/unreadable file and is about six years old.
 



I've migrated from one Mac operating system to another using Migration Assistant many times, mostly because of laziness. And, in gereral, it's worked well. For whatever reason, though, when I decided to upgrade both my Mac Pro and my MacBook Pro to Sierra, I decided to do it the hard way... and I was very pleasantly surprised with the results.
...
Doing this from scratch isn't for everyone, but it was actually much less painful than I feared, and I was very satisfied with the result. I don't know if the system is any more stable because I started from scratch, but at least I don't have to wonder if that's a factor.
As a long time tester of OS X and macOS beta releases, I routinely follow the procedure outlined by Darryl, especially for the initial beta for each OS version. This tends to narrow the scope for problem analysis to whatever I have just installed. I don't have to search the detritus from older installs.
 


Ric Ford

MacInTouch
I tried that, too, but the Enable Users button does nothing when I click it.
It sounds like there's some sort of configuration problem that I don't understand.

But, if you want, you could explore more with the command-line utility fdesetup.
Bash:
sudo fdesetup list users
man fdesetup
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts