hoakley July 21, 2021 Macs, Technology

Owners and users: Primary and secondary systems on M1 Macs

Knowing now that on M1 Macs there are not only admin users but also Owners, this article looks in more detail at how Ownership works, particularly in setting the Mac up initially and when installing second operating systems, such as a copy of macOS on an external disk. Apple provides details in its Platform Security Guide, so here I’ll try to explain them, and their problems.

Initial key and certificate creation

There are two situations in which an M1 Mac needs to be set in its default state: when it’s brand new, and when it has been fully erased and restored in DFU mode using Apple Configurator 2. As Apple explains: “When macOS is first installed in the factory, or when a tethered erase-install is performed, the Mac runs code from temporary restore RAM disk to initialize the default state. During this process, the restore environment creates a new pair of public and private keys which are held in the Secure Enclave. The private key is referred to as the Owner Identity Key (OIK). If any OIK already exists, it’s destroyed as part of this process.”

So during this creation of the default state, the OIK, the private half of a public-private key pair, is generated and stored in the Secure Enclave. Also created is a new User Identity Key (UIK) for Activation Lock. This is sent to Apple for certification, where it’s checked to see if it’s associated with a lost Mac using the Find My Mac service. If it is, then certification is refused and that attempt to set that Mac up fails. If the UIK is certificated successfully, then that User Identity Certificate (ucrt) is used to sign in RemotePolicies, which provide constraints for LocalPolicies.

The ucrt and OIK are then used to obtain an Owner Identity Certificate from Apple: “When an Activation Lock/ucrt is successfully retrieved, it’s stored in a database on the server side and also returned to the device. After the device has a ucrt, a certification request for the public key which corresponds to the OIK is sent to the Basic Attestation Authority (BAA) server. BAA verifies the OIK certification request using the public key from the ucrt stored in the BAA accessible database. If the BAA can verify the certification, it certifies the public key, returning the Owner Identity Certificate (OIC) which is signed by the BAA and contains the constraints stored in ucrt. The OIC is sent back to the Secure Enclave. From then on, whenever the Secure Enclave signs a new LocalPolicy, it attaches the OIC to the Image4.”

At the end of these processes, the Mac has an OIC, kept in the Secure Enclave, which is used to attach to all LocalPolicies for that Mac, a private OIK, also kept in the Secure Enclave, RemotePolicies which are signed into the ucrt, and a UIK for Activation Lock.

These processes are summarised here:

which is also available as a downloadable PDF: SettingM1Mac1

Ownership

Creating and maintaining LocalPolicies requires a user to have access to the private OIK in the Secure Enclave, making that user an Owner. Apple states: “Access to the Owner Identity Key (OIK) is referred to as “Ownership.” Ownership is required to allow users to resign the LocalPolicy after making policy or software changes.”

Who is an Owner?

Any user with access to the OIK is therefore an Owner. Although there’s only one OIK for any given M1 Mac, and by default only the primary admin user has access to it: “The OIK is protected with the same key hierarchy as described in Sealed Key Protection (SKP), with the OIK being protected by the same Key encryption key (KEK) as the Volume encryption key (VEK). This means it’s normally protected by both user passwords and measurements of the operating system and policy.”

So any user with access to the Volume Encryption Key for the internal storage also has access to the OIK, and has Ownership. By default, that includes all users added after FileVault encryption is enabled on a Data volume, for example.

Installing a second operating system

M1 Macs always start their boot process from their internal storage, even when they’re then going to boot from a second operating system stored elsewhere. To be able to boot from that second OS, it requires a LocalPolicy with an OIC attached, and Ownership has to be handed off to an Install User created when that OS is installed. Creating and changing that LocalPolicy thus requires Ownership, for which the same password is required as for access to encrypted internal storage.

Handing off Ownership to the Install User is more of a problem, as users are only created once the installation is complete. To accommodate that, macOS offers to copy a user from the current boot system as the Install User, and the primary admin user, on the second OS. Apple states: “When running an Install Assistant and targeting installation for a secondary blank volume, a prompt asks the user if they’d like to copy a user from the current volume to be the first user of the second volume. If the user says yes, the “Install User” which is created is, in reality, a KEK which is derived from the selected user’s password and hardware keys, which is then used to encrypt the OIK as it’s being handed to the second operating system. Then from within the second operating system Install Assistant, it prompts for that user’s password, to allow it to access the OIK in the Secure Enclave for the new operating system.”

Apple strongly recommends that this offer is accepted, as it ensures that the Install User can access the OIK, and that security is fully preserved. However, if the user decides not to copy the current user, macOS will create an Install User with a blank password.

These processes are summarised here:

and in the downloadable PDF version: Install2ndOSM1

Addressing problems

These are complex processes which don’t always work as expected, particularly when using beta releases. You can make them more reliable by:

Retaining the primary admin accounts created on the first OS on internal storage, and any second OS on internal/external storage. Although creating a second account may work perfectly well, the original Owner and Install User accounts are likely to prove the most reliable.
Installing second OS from the primary admin account on the primary OS.
Installing macOS updates from the primary admin account of that OS.
Copying the Install User from the first OS to a second, as invited during installation.

Problems normally manifest in failure to install a second OS, or failure to update it. Sometimes an attempt may be blocked, with an alert reporting that the disk has no Owner, or an update may apparently proceed normally, but fail to change the version of macOS installed. Although macOS should always prompt the user for the Owner’s password on such occasions, and make clear which user that is, if that doesn’t happen access to the OIK may fail.

There currently appears to be no way to identify Owners or Install Users. Even the command tool bputil doesn’t appear to provide that information. File system ‘volume ownership’ appears to be completely unrelated to this type of Ownership.

51Comments

Add yours

1

Blog101 on July 21, 2021 at 6:37 am

Needing a 2nd Mac to make an M1 Mac is insane. We should be able to restore an M1 Mac from an iPhone or iPad too.

LikeLiked by 2 people
- 2
  
  hoakley on July 21, 2021 at 7:21 am
  
  Thank you.
  Yes, it would be if it were true. Nowhere above do I state that’s required, nor does Apple. When you take delivery of a new M1 Mac, it sets up as described without the need or use for any other Mac.
  M1 Macs introduce a new feature – one not available in any previous Mac – in that you can completely erase its firmware, Recovery, etc., and restore it to the factory default state. For fairly obvious reasons, this is non-trivial, although very quick and a straightforward procedure.
  Howard.
  
  LikeLike
  - 3
    
    Simon on July 21, 2021 at 2:32 pm
    
    Howard, can you point us to a brief description of how that is achieved? (for those of us without an M1 Mac to try out) Is this resetpassword in Recovery Terminal or does it involve a Recovery menu command? A lot of articles online just talk about booting into Recovery, formatting the Data partition, and then re-installing macOS form Recovery. But obviously, that’s a clean install, not a factory reset where you’d also expect brand new firmware etc. Some articles mention Configurator 2 which will actually get the real factory reset done, but of course requires a 2nd Mac connected through USB-C cable. If you have a simple write-up on how to accomplish the real factory reset w/o 2nd Mac and Configurator 2, it would be great if you could drop that link. As always, thank you, Sir.
    
    LikeLiked by 2 people
    - 4
      
      hoakley on July 21, 2021 at 2:34 pm
      
      Thank you. That’s coming tomorrow morning.
      Howard
      
      LikeLike
5

Tim R on July 21, 2021 at 10:19 am

OK, that makes sense. For someone wanting to do a “clean install” the prospect of “copying over a user” is one that’s likely to be refused, as it’s easily assumed that you’re copying over all of that user’s data. But if it’s just copying over owner information (right?), that seems acceptable (even preferable in the context of this platform).

LikeLiked by 1 person
- 6
  
  hoakley on July 21, 2021 at 12:26 pm
  
  Thank you. I’d need to check here, but it doesn’t perform migration. With the sealed System volume, all installs are clean anyway – that’s now the only way to run macOS.
  Howard.
  
  LikeLike
  - 7
    
    Tim R on July 21, 2021 at 12:44 pm
    
    Ah, true. I guess I just like to wipe out (with backups of course) my user Library folder every year with a new macOS version. Thousands of files with multiple GB of space for items I’m not sure I need or want is my complaint, and just going in and deleting things isn’t always a good strategy. Cheers.
    
    LikeLiked by 1 person
8

Tim R on July 21, 2021 at 10:49 am

Also, for people in the last writeup worrying about being able to sell your Mac and have all this work, I’m starting to think Monterey’s “Erase All Content and Settings” is exactly the way to go. When they announced it we obviously didn’t have the context of an Owner account (genuine thanks Howard!), but it makes perfect sense that this function will (at least should) take care of all of that.

LikeLiked by 2 people
- 9
  
  hoakley on July 21, 2021 at 12:27 pm
  
  Thank you.
  Funnily enough, that’s my topic for tomorrow’s article!
  Howard.
  
  LikeLike
10

brightlondon on July 21, 2021 at 11:40 am

Thank you Howard for yet another fascinating investigation and explanation. Your work really is invaluable.

You said “any user with access to the Volume Encryption Key for the internal storage also has access to the OIK, and has Ownership”. I just wanted to make sure I hadn’t misunderstood that statement as it seems quite surprising.

With FileVault turned on, any user on the system (including non-admin users) has access to the VEK so they can unlock the drive on logging in. And to access the VEK they need the Key Encryption Key (KEK), which they obtain by entering their password. But the KEK also protects the OIK. If they have access to the OIK they are an Owner. So everyone with a login account on that Mac is an Owner, even Standard users. Have I misunderstood your statement, or is it that only the Owner account can use the KEK to access the OIK, and all other account can only use the KEK to access the VEK? (Sorry about all the TLAs but they save my fingers a lot of work!)

LikeLiked by 2 people
- 11
  
  hoakley on July 21, 2021 at 12:35 pm
  
  Thank you.
  The situation is a bit more complex if you think it through. An example:
  I have a single admin user on my M1 Mac’s primary macOS. I then install another macOS on an external disk, which isn’t encrypted, and when booted in that macOS I create a second admin user to the first which is a copied Owner.
  As there’s no FileVault on the external disk and it isn’t now the boot disk either, neither user there has access to the VEK for the internal storage. So the Install User (Owner surrogate) of that external disk remains its first admin user, and not the second.
  Should the second user want to install a macOS update – an action which requires Ownership – macOS should prompt them for the first user’s password to satisfy the requirement of Ownership.
  Of course, if there’s a bug and that doesn’t happen, the update will be blocked or fail, until the first admin user logs on, when they will be able to perform the update.
  Moral: KISS. Then you won’t be the victim of such puzzling bugs.
  Howard.
  
  LikeLike
  - 12
    
    ninjaturtle45 on July 28, 2021 at 5:03 am
    
    “As there’s no FileVault on the external disk and it isn’t now the boot disk either, neither user there has access to the VEK for the internal storage. So the Install User (Owner surrogate) of that external disk remains its first admin user, and not the second.”
    
    I would presume that in such a case, macOS performs a workflow similar to that of transitioning from a disk user to the first administrator user, as described below.
    
    Ever since the birth of APFS in macOS High Sierra, if you create a new encrypted APFS volume, a “Disk” user (i.e. a wrapped KEK, aka a Secure Token) is automatically created, and it is used to protect the VEK used to encrypt the volume.
    
    Installing macOS High Sierra or later onto that volume has some interesting consequences. In particular, when the Setup Assistant appears, the Disk User password is required in order to continue setup. This is because with APFS, macOS (almost always) generates the FileVault key infrastructure (along with Secure Tokens) at Setup Assistant. On an unencrypted boot volume, this would automatically occur in the background, but on an encrypted boot volume, a VEK already exists, and the Secure Token held by the “Disk User” needs to be unlocked so that the KEK can be handed off to the first administrator user. Once the new admin receives the KEK, it is wrapped with the admin’s password to create a new Secure Token for that admin.
    
    In macOS High Sierra and Mojave, once the KEK has been handed off to the new admin, no further action happens with the Disk User. In fact, it still remains on the system, and allows for some interesting FileVault setups using “fdesetup” – such as forcing the Disk User password on the decryption screen, and then requiring a user login password on the real login screen.
    
    However, in macOS Catalina and later, once the KEK has been handed off to the new admin, the existing Disk User is destroyed, and the new admin is now the only user in possession of a Secure Token. Although this removes the possibility of two-password authentication for FileVault, it ensures that users can’t accidentally abuse the Disk User, and that it doesn’t appear on the FileVault login screen.
    
    As far as I’m aware, M1 Macs with Big Sur treat Install Users the same way as Disk Users would be treated in macOS Catalina and later. When a new (not first) installation is started, the following occurs (as mostly described by your article):
    
    1. The admin’s password is used to unwrap the OIK.
    
    2. macOS makes a copy of the OIK, and wraps it using a new KEK generated for the new macOS installation.
    
    3. macOS creates a new “Install User”, and (appears to) wraps the KEK using hardware keys, most likely the ones described for Sealed Key Protection in Apple’s Platform Security document. If an owner on the first macOS installation chooses to copy a user, that user’s passphrase is also used to wrap the new KEK.
    
    In other words, it pretty much made a “user” with a Secure Token, in the same fashion as a Disk User (plus the hardware keys).
    
    4. When Setup Assistant fires up on the second copy of macOS, it attempts to unwrap the Secure Token held by the Install User, and obtain the KEK. If no user was copied, this is successful (since only hardware keys were used); if a user was copied, that user’s passphrase is also required in order to unwrap the Secure Token.
    
    5. At user account creation time, macOS wraps the KEK using the new admin’s password, thus creating a Secure Token for the new admin.
    
    6. The second copy of macOS destroys the Install User, in the same fashion it would with a Disk User. At this point, the new admin has sole ownership on the second copy of macOS. (Of course, the admins on the first macOS installation still have access to the OIK and retain ownership as well.)
    
    (For step 6, try running “diskutil apfs listusers /”. In my case, I didn’t find any install users listed.)
    
    LikeLiked by 1 person
    - 13
      
      hoakley on July 28, 2021 at 12:47 pm
      
      Thank you.
      Interestingly, I had exactly the same problem again last night: when I tried to install a macOS update from a second admin account on an external disk, I was informed that as the disk had no owner, it wasn’t possible. That’s on an unencrypted APFS disk. So something isn’t working out (still).
      Howard.
      
      LikeLike
14

Milo on July 21, 2021 at 3:22 pm

I tried to follow your explanation, but I can’t quite wrap my head around the topic of “Owndership”.

For years my standard procedure when migrating to a new Mac has been to create a temporary user for the puropse of finishing the installation of the Mac. Then in a second step I would move my old user account with the help of Migration Assistant. Usually I would then delete the first admin account (the one created during installation).

The reason for this procedure ist that my old account for historical reasons has the UID 502. The first user created on a cleanly installed macOS has the UID 501.

Could the procedure above in any way cause problems when done a M1 Mac? What I mean is if I could potentially loose access to the “Ownership” status when deleting the first admin account?

LikeLiked by 1 person
- 15
  
  hoakley on July 21, 2021 at 8:45 pm
  
  Thank you.
  There’s no problem at all in running as a second admin user if you still need to work as user 502. I’m not sure that I’d delete the 501 user though on an M1 Mac. While you shouldn’t need it when everything’s working fine – it’s also an Owner, of course – if something goes wrong with an installer/updater it could be a useful fallback which could save you having to run the full installer. But you shouldn’t need to.
  Howard.
  
  LikeLike
  - 16
    
    Milo on July 22, 2021 at 9:55 am
    
    Thank your for your assesment. If there was a need to reinstall the system in such a constellation that would be a major inconvenience. I do hope Apple developers have considered most of the common edge cases.
    
    I understand that these cryptographic measures are supposed to make the macOS boot process more secure. On the other hand the added complexity does create new problems and possibly new bugs.
    
    The ability to easily boot from external media is a convenient method to troubleshoot problems with Mac hardware. It would be a pity if we effectively lost this ability due to the new security measures.
    
    LikeLiked by 1 person
    - 17
      
      hoakley on July 22, 2021 at 11:39 am
      
      Thank you.
      Two things about reinstalling the system:
      1. You don’t need to do this. Hardly ever. The Sealed System Volume is actually a read-only snapshot. Not even macOS itself can change it. The days of reinstalling the system because something has gone wonky with it are gone.
      2. When you do need to reinstall the system, the installer will normally preserve your Data volume and hook up the new system to that. Even if it can’t, it lets you migrate from a copy or backup. So you can continue running as 502 with no inconvenience.
      The complexity in this new system isn’t in the System itself, it’s in the installation and making of it, which either works or it doesn’t. And installers are getting more flexible and reliable all the time.
      To troubleshoot your hardware, you have Diagnostics, in recoveryOS. You don’t need an external disk for that – indeed an M1 can only run recoveryOS and Diagnostics from the internal storage. That makes life simpler, not more complex, and is nothing to do with security.
      Howard.
      
      LikeLike
    - 18
      
      Milo on July 22, 2021 at 1:09 pm
      
      Answering here because of the limitations of the comments system.
      
      Thank you for expanding on your explanation. I think I get it now. You have to think about macOS on the M1 platform more like a more customizable iOS with a seperate Data partition that is still under my control.
      
      It’s quite a paradigm shift after two decades of tinkering with Windows, Linux or OS X/macOS on a low level and will need some time to get used to. Although I’m sure that the vast majority of macOS users won’t care at all or even notice the difference.
      
      LikeLiked by 1 person
    - 19
      
      hoakley on July 22, 2021 at 7:58 pm
      
      Thank you.
      I’ll be writing an explainer for Saturday morning.
      Howard.
      
      LikeLike
20

Michael Tsai - Blog - Owner Accounts on M1 Macs on July 26, 2021 at 7:13 pm

[…] Update (2021-07-26): Howard Oakley: […]

LikeLike
21

Joe on July 28, 2021 at 3:27 pm

re:”Also created is a new User Identity Key (UIK) for Activation Lock. This is sent to Apple for certification, where it’s checked to see if it’s associated with a lost Mac using the Find My Mac service. If it is, then certification is refused and that attempt to set that Mac up fails.”

Is this check a requirement to use the mac? For example, what if the mac is not connected to internet?

Other than checking to see the mac is not a lost mac, are there any other requirements which must be passed to use the mac?

I can understand the security benefits of checking for lost macs, but anything else seems to add the potential to interfere with the use and enjoyment of the mac by users.

LikeLiked by 1 person
- 22
  
  hoakley on July 28, 2021 at 3:57 pm
  
  Yes. All M1 Macs need to be activated when connected to the Internet so that this can be performed. It’s hardly an arduous task, and doesn’t interfere with anything. Are you suggesting that Apple might deliberately stop some IP addresses from being able to activate?
  Howard.
  
  LikeLike
  - 23
    
    Joe on July 28, 2021 at 4:18 pm
    
    re: “Are you suggesting that Apple might deliberately stop some IP addresses from being able to activate?”
    
    No. I am suggesting that mac users should not be dependent upon Apple to decide to allow them to use a computer.
    
    LikeLiked by 1 person
    - 24
      
      hoakley on July 28, 2021 at 5:15 pm
      
      No: this is not a question of whether you can use a Mac, but an initial step which your M1 Mac has to go through when you first use it. Once it has been done, it isn’t required again unless the Mac is restored in DFU mode. That prevents someone who has stolen that Mac from simply restoring it, and selling it as new. So long as you enable Find My Mac for it, you get that protection free in every M1 Mac. Unless you’re a pro thief, I can only see that as a big benefit to M1 users.
      Howard.
      
      LikeLike
25

Joe on July 28, 2021 at 3:44 pm

re: “Apple states: “When running an Install Assistant and targeting installation for a secondary blank volume, a prompt asks the user if they’d like to copy a user from the current volume to be the first user of the second volume. If the user says yes, the “Install User” which is created is, in reality, a KEK which is derived from the selected user’s password and hardware keys, which is then used to encrypt the OIK as it’s being handed to the second operating system. Then from within the second operating system Install Assistant, it prompts for that user’s password, to allow it to access the OIK in the Secure Enclave for the new operating system.”

Apple strongly recommends that this offer is accepted, as it ensures that the Install User can access the OIK, and that security is fully preserved. However, if the user decides not to copy the current user, macOS will create an Install User with a blank password.”

If the OIK is not copied when prompted for password, then what happens as a result?

Will the new system be orphaned and thus unusable?

Or can the new system be activated somehow by connecting to the original OIK? to a different OIK from a different mac?

LikeLiked by 1 person
- 26
  
  hoakley on July 28, 2021 at 3:59 pm
  
  No, as written, the Install User will still be created, but will then have a blank password, which reduces its security and impacts on the Secure Boot process. I strongly recommend it, as if you don’t, you could experience problems installing macOS updates, and have to use the full installer instead, which rapidly gets tedious.
  Howard.
  
  LikeLike
27

Joe on July 28, 2021 at 3:45 pm

It seems frustrating that in Apple’s efforts to increase security, Apple is diminishing the capability of users to use and enjoy their macs as they might choose- here, by starting their mac with any working version of the system on any external disk of their own choosing. There are many reasons for doing so- testing new systems, experimenting with different configurations, maintaining backups, having multiple working configurations for different application purposes, etc.

Perhaps one of the best reasons for different systems on external disks is to achieve what Apple here is specifically thwarting- to run one particular system on different macs with no variation other than the mac it is running on. For example, taking work on a particular external startup disk to different locations to work uninterrupted on different macs in different physical locations.

Requiring one particular mac to be the key required to run a particular system is a serious obstacle for these workflows. Very troubling.

LikeLiked by 1 person
- 28
  
  hoakley on July 28, 2021 at 4:05 pm
  
  Thank you.
  M1 Macs can only run Big Sur or betas of Monterey, so they’re already limited in the versions of macOS they can run.
  By disabling Secure Boot, you can build your own kernel and use it on your M1 Mac if you wish. You can also create an external boot disk which you use to boot two different M1 Macs, in exactly the way that you claim that Apple is preventing.
  What every M1 Mac does, though, is to start its boot process from its internal SSD – that’s different from all Intel models, and is necessary for several good reasons, including the Secure Boot process which verifies the integrity of the iBoot firmware, and its internal recoveryOS, which can’t be provided on an external disk.
  Howard.
  
  LikeLike
  - 29
    
    Joe on July 28, 2021 at 4:32 pm
    
    re: ” You can also create an external boot disk which you use to boot two different M1 Macs, in exactly the way that you claim that Apple is preventing.”
    
    I am missing or misunderstanding how things work or don’t work. The OIK on the mac and the OIK (OIC, actually) on external startup disk do not have to match, if the mac has disabled Secure Boot? If so, then that allows the workflows I described, is that correct?
    
    LikeLiked by 1 person
    - 30
      
      hoakley on July 28, 2021 at 5:21 pm
      
      Apple doesn’t explain that, I’m afraid. However, those aren’t saved on the external disk, but in the Secure Enclave. So I don’t see any reason that one external disk can’t be used to boot several M1 Macs.
      What may be more interesting, though, is getting that to update! I can see that could be fun!
      Howard.
      
      LikeLike
    - 31
      
      hoakley on July 28, 2021 at 5:26 pm
      
      If you’re interested in the odyssey I’ve had getting external bootable disks to work with M1 Macs, there’s a section listing all my articles in the M1 page in the top menu on this page. It’s long and bitter at times, but I’ve got there.
      Howard.
      
      LikeLike
    - 32
      
      Joe on July 28, 2021 at 6:00 pm
      
      re: “the odyssey I’ve had getting external bootable disks to work with M1 Macs”
      
      Yes, I have followed along with some of it because it is an essential function that is critically important.
      
      Thank you for sharing the information, all the work involved, and providing the forum for further discussion. I am sure it is helpful to many and I would hope that Apple has an ear to the problems and concerns being addressed and examined here.
      
      Again, it cannot be said how much help is provided here and how thankful we are for all the efforts.
      
      LikeLiked by 1 person
    - 33
      
      hoakley on July 28, 2021 at 9:16 pm
      
      Thank you for your kind words.
      Howard.
      
      LikeLike
34

Joe on July 28, 2021 at 4:27 pm

re:”M1 Macs can only run Big Sur or betas of Monterey, so they’re already limited in the versions of macOS they can run.”

OK. But even within the limitations you describe are multiple variations of the system a user may choose to startup. Apple beta instructions, and common sense, involve running beta as an alternative to the user’s working production system. I don’t believe this should require a second computer to do. Or to do any other work using different startup systems. Are you suggesting it should?

LikeLiked by 1 person
- 35
  
  hoakley on July 28, 2021 at 5:18 pm
  
  It doesn’t require a second Mac.
  I have an M1 Mac mini which is currently booted from an external SSD running an Apple beta-release. It also boots fine into macOS 11.5 on its internal SSD. I have another SSD which I can boot it from which has at least 3 different versions of Big Sur on it, all bootable from that same Mac.
  So what’s the problem?
  Howard.
  
  LikeLike
  - 36
    
    Joe on July 28, 2021 at 5:37 pm
    
    No problem. I was confused by the statement “M1 Macs can only run Big Sur or betas of Monterey, so they’re already limited in the versions of macOS they can run.” I thought the statement was made because it was relevant to my comment because the statement was in the reply. But now I see it wasn’t relevant, just an observation in general, which, of course, is an accurate one. So it was just extraneous information in response to my comment- but, also of course, something which might be helpful for anyone else reading here.
    
    LikeLiked by 1 person
    - 37
      
      hoakley on July 28, 2021 at 5:39 pm
      
      No, it’s not extraneous. You said that you wanted to be able to run the macOS of your choosing. I’m afraid that your choice is already limited: there’s no way to run Mojave, for instance.
      I’m sorry that my answer confused you, but it seems crystal clear to me.
      Howard.
      
      LikeLike
  - 38
    
    Joe on July 28, 2021 at 5:52 pm
    
    re: “You said that you wanted to be able to run the macOS of your choosing”
    
    No. That is not what I said. I described starting up on different external startup drives, in some cases using different system versions.
    
    Why would you assume that meant trying to run systems which are not compatible with the mac?
    
    That is what was confusing to me, not the information. Thanks.
    
    LikeLiked by 1 person
    - 39
      
      hoakley on July 28, 2021 at 5:59 pm
      
      You wrote above:
      “Apple is diminishing the capability of users to use and enjoy their macs as they might choose- here, by starting their mac with any working version of the system on any external disk of their own choosing”
      I have working versions of macOS which I use with Intel Macs which an M1 can’t boot. You didn’t specifically exclude those, so I was making it clear that M1 Macs can’t boot any version of macOS prior to 11.0, which is a severe constraint in the beginning, given that there have only been ten versions of macOS 11 which an M1 Mac can run. I’m sorry if that might have confused you, but can’t imagine how it did.
      Howard.
      
      LikeLike
  - 40
    
    Joe on July 28, 2021 at 6:13 pm
    
    I did say “working version”. Perhaps I should be apologizing to you, for your confusion in believing that “working version” meant a version which could not work on a mac it was connected to. My mistake for assuming that everyone would understand that a “working version” meant a version that would work on the mac it was connected to (apart from new Apple security requirements to do so).
    
    To be more clear, consider the case of physically taking the internal startup drive from one mac and moving it into a different identical model mac.
    
    What might have been a commonplace troubleshooting step is now prohibited by Apple.
    
    I understand and recognize the efforts and great lengths you have gone to examine these issues.
    
    Sometimes I am dismayed by the nonchalance which the changes made by Apple are greeted with, because these changes have severe negative impacts in some cases.
    
    LikeLiked by 1 person
    - 41
      
      hoakley on July 28, 2021 at 9:16 pm
      
      There’s no need for apologies – it’s more important that we understand one another.
      Unfortunately, the case you cite isn’t actually specific to the M1 Macs. No Mac with a T1 or T2 chip has removable internal storage, unless you fancy desoldering its SSD. If you think about it, there’d be absolutely no point in a T1/T2 or the Secure Enclave in the M1 if you could just pop out its internal storage.
      So that has already been prohibited by Apple since 2016, which is five years ago.
      I’d be very interested to hear of a “severe negative impact” resulting from this change, other than it preventing others from accessing the contents of that Mac, and repurposing a stolen Mac and selling it.
      Howard.
      
      LikeLike
42

Joe on July 28, 2021 at 5:30 pm

Can external startup disk be started up to install system on a second external disk?

LikeLiked by 1 person
- 43
  
  hoakley on July 28, 2021 at 5:35 pm
  
  I’m sorry I haven’t a clue. As you can’t boot an M1 Mac without an internal SSD, that’s academic.
  Howard
  
  LikeLike
  - 44
    
    Joe on July 28, 2021 at 5:40 pm
    
    re: “As you can’t boot an M1 Mac without an internal SSD, that’s academic.”
    
    No, it’s not academic. It is possible to attach more than one external drive to an M1 mac which contains an internal SSD while starting up from one of the external drives, is it not?
    
    LikeLiked by 1 person
    - 45
      
      hoakley on July 28, 2021 at 5:41 pm
      
      Yes.
      
      LikeLike
46

Jerry on August 14, 2021 at 11:30 am

Normally I setup a an admin user on a new Mac to upgrade it then migrating things from another com puter and then erasing the first temporary admin user – one would hope that is not a problem and the new admin user should really be the owner, but guess that won’t be much of a problem in real life (an you were talking of setting up a secondary OS).

LikeLiked by 1 person
- 47
  
  hoakley on August 14, 2021 at 1:50 pm
  
  Yes, that should continue working fine, as your 502 user is given access to the internal encrypted volumes, so can be an owner. However, it might of course leave you with ‘missing 501’ problems, but I think you know how to avoid those.
  Howard.
  
  LikeLike
48

Jan on November 1, 2021 at 8:15 am

Thank you for sharing all of your findings. I’ve been reading your posts trying to understand all of it but I’m not very technical so please bear that in mind.

I began my research hoping to be able to install MacOS on an external SSD and for it be portable with other machines but it sounds like this is no longer possible with the M1 Macs. Is that correct?

The OS on an external SSD has to be the same Owner and User as the one initiated on the internal SSD in order for it to be bootable and if you want to be able to update the OS. The internal SSD functions like a key required to boot the OS on both the internal and external SSDs. I hope my understanding is correct so far. Is there a way to restore the contents of the OS running on the external SSD to another Mac or to another SSD if the Mac with the internal SSD stops working?

If the Owner/User of the OS from an external SSD must be the same Owner/User as the internal SSD and if Apple phones home when activating the Owner on the internal SSD. Would this effectively allow Apple to surveille which Mac owner is operating which OS? It seems like a nice feature that prevents a thief from being able to boot from the external SSD using any computer but it also seems like a slippery slope when viewed from a privacy perspective.

You mentioned that not having these new feature prevents “others from accessing the contents of that Mac, and re-purposing a stolen Mac and selling it.” How does it prevent a thief from wiping the internal disk and start as a new Owner and User? Doesn’t this go counter to when you said “M1 Macs introduce a new feature – one not available in any previous Mac – in that you can completely erase its firmware, Recovery, etc., and restore it to the factory default state.”

LikeLiked by 1 person
- 49
  
  hoakley on November 1, 2021 at 8:56 am
  
  Thank you.
  No, you can create a bootable external disk for M1 Macs which you boot multiple M1 Macs from. I’ve done it, and test it occasionally. That’s in Big Sur, but I expect Monterey to be even better with that arrangement.
  You don’t restore the OS on an internal SSD from an external. Although that sometimes may work, it’s not recommended. The way that you restore macOS on an internal SSD (or an external, for that matter) is to install it on there, either using the full Installer app or in Recovery.
  I’m fairly certain that activation, which is performed with Apple’s servers, doesn’t track which macOS you’re using. In any case, you normally only activate an M1 Mac once, when you first set it up.
  Yes, a thief can use Apple Configurator 2 with the M1 Mac in DFU mode to restore the whole of its firmware and macOS. However, before that Mac can be used again it then has to be activated with Apple’s servers. If it has been reported as being stolen, Apple can then refuse that activation, in which case it can’t be used.
  I hope that’s clearer.
  Howard.
  
  LikeLike
  - 50
    
    Jan on November 2, 2021 at 2:33 am
    
    “No, you can create a bootable external disk for M1 Macs which you boot multiple M1 Macs from. I’ve done it, and test it occasionally.”
    
    Is there an article you can recommend I follow in order to do this successfully? From the articles that I’ve read, I was under the impression that the Ownership issue was still getting in the way. Basically that if I activate the external SSD on Mac #1, it would require Owner/User combination of the internal SSD on Mac #1. If I try to boot from another Mac #2, it wouldn’t let me boot the external SSD since the Owner/User is different.
    
    “You don’t restore the OS on an internal SSD from an external. Although that sometimes may work, it’s not recommended.”
    
    What should one do if you have been booting from an external SSD but would like to use that as their main OS on the internal drive of a Mac? Would the best option be to wipe out the internal drive and use a time machine backup of the external SSD with Migration Assistant?
    
    “I’m fairly certain that activation, which is performed with Apple’s servers, doesn’t track which macOS you’re using. In any case, you normally only activate an M1 Mac once, when you first set it up.”
    “However, before that Mac can be used again it then has to be activated with Apple’s servers. If it has been reported as being stolen, Apple can then refuse that activation, in which case it can’t be used.”
    
    After Apple’s proposal to scan picture taken on an iPhone, I’ve become more suspicious of their direction but maybe I’m been too cynical. Do you know if activation of a M1 Mac requires you to have an Apple ID, was able to get the serial number, or your Owner/User name? If apple is able to know if a Mac that was activated once is the same one when a thief tries to activate it again, it probably means the activation key is a cryptographic key unique to each M1 Mac. At the very least it requires an internet connection but I’m wondering if the key used for the activation and the serial number of the Mac can be tied together through the registration process.
    
    Thanks Howard.
    
    LikeLiked by 1 person
    - 51
      
      hoakley on November 2, 2021 at 7:17 am
      
      I have a collation of articles specific to M1 Macs in the page with that name, accessible in the top menu here. There’s a whole section on bootable external disks there which I commend to you. This changed dramatically around 11.4 – prior to that, they were really difficult, but Apple fixed the great majority of problems.
      To install macOS on your internal SSD, you can either run the macOS Installer app (possibly from a bootable external disk, if you wish) or you can install it from within Recovery. If you want to start from scratch, it’s easy to wipe the macOS container, and you can then migrate during or following macOS installation. Again, the options are examined in articles linked to from the M1 page.
      I’m puzzled that you’re more suspicious of Apple after the debate over its proposals to scan images. I’d be a lot more suspicious if Apple hadn’t explained its intentions, but gone ahead. I don’t follow the reasoning that because Apple was open about what it wanted to do, it’s going to try inflicting something secretly.
      AFAIK activation doesn’t require an AppleID – yesterday when I was trying to set up my new MacBook Pro, it was happy to activate even though it failed to connect using my existing AppleID and I had to set that up manually later. However, activation certainly requires the hardware UUID of that Mac in some form, and can match that up with known thefts tracked through the Find My system. But I don’t think that Apple associates that with any individual, it’s just the Mac itself which is identified.
      Compared to all the other data that Apple has about Mac users, this seems trivial to me. What I find even funnier is that Apple does so little with all this data, demonstrating how ephemeral it must be. For example, I don’t limit the info Apple collects from my iPhone, but it shows ads in the Health app for fertility and ovulation trackers, and today for helping manage the menopause. As I’m a 67 yr-old man, the fact that Apple doesn’t even target those by age and gender speaks volumes about how little it really does ‘know’ about me in spite of all the info it has obtained!
      Howard.
      
      LikeLike