Archive

Archive for the ‘Apple File System’ Category

Creating, managing and using Apple File System snapshots for startup drive backups

May 8, 2019 2 comments

Starting with macOS High Sierra, Time Machine on Apple File System-formatted (APFS) startup drives gained the ability to create APFS snapshots. These snapshots capture the state of the startup volume at a particular point in time and can be used by Time Machine to restore files, folders or the whole startup volume. These snapshots are stored on the startup volume, but are not the same as the previous local backups that Time Machine used on Hierarchical File System Plus (HFS+) formatted drives.

On HFS+ formatted drives, Time Machine local backups are stored in an invisible directory named .MobileBackups on the root level of the startup drive.

Figure 1 Location of the MobileBackups directory on an HFS+ formatted boot drive

This .MobileBackups directory is mountable as /Volumes/MobileBackups and you can access the backed-up files stored inside by navigating via the command line or Finder window.

Figure 2 Navigating the mounted MobileBackups volume

On APFS formatted drives, the /.MobileBackups directory and /Volumes/MobileBackups are no longer available. Instead, Time Machine is now using APFS snapshots to store a read-only copy of the state of your Mac’s startup drive at the time when that snapshot was taken. These snapshots are invisible to the file system, so unlike HFS+, there isn’t a directory or file location which you can access to get access to the snapshot-stored backups.

Snapshots include all files and directories stored on the startup drive at the time that the individual snapshot was made. When available, these snapshots can be used to restore the following:

  • Individual files
  • Individual directories
  • Multiple files at once
  • Multiple directories at once
  • All files and directories at once

If the startup drive was encrypted at the time the snapshot was made, the snapshot will itself be encrypted. This allows the restoration of an encrypted startup drive without needing to decrypt or re-encrypt the relevant startup drive. For more details, please see below the jump.

Read more…

Mounting Time Machine local snapshots as read-only volumes

February 23, 2019 Leave a comment

Starting with macOS High Sierra, Time Machine on Apple File System-formatted (APFS) boot drives gained the ability to create APFS snapshots. These snapshots are stored on the boot volume, but are not the same as the local backups that Time Machine uses on HFS+-formatted drives.

On HFS+ formatted drives, Time Machine local backups are stored in an invisible directory named .MobileBackups on the root level of the boot drive.

Screen Shot 2019 02 23 at 10 44 17 AM

In turn, this .MobileBackups directory is mountable as /Volumes/MobileBackups and you can access the backed-up files stored inside by navigating via the command line or Finder window.

Screen Shot 2019 02 23 at 10 59 43 AM

On APFS-formatted drives, the /.MobileBackups directory and /Volumes/MobileBackups are no longer available. Instead, Time Machine is now using APFS snapshots to store a read-only copy of the state of your Mac at the time when that snapshot was taken. These snapshots are invisible to the file system, so unlike HFS+, there isn’t a directory or file you can access. Instead, you now need to use the mount_apfs command’s -s option to mount APFS snapshots as read-only volumes.

Screen Shot 2019 02 23 at 11 45 51 AM

For more details, please see below the jump.

Read more…

Re-syncing local account passwords and Secure Token on FileVault-encrypted Macs running macOS Mojave

February 10, 2019 5 comments

As part of FileVault on Apple File System, Apple introduced a new account attribute called Secure Token. As mentioned in a previous post, Secure Token can present some interesting problems for Mac admins who work with FileVault-encrypted laptops. Among the potential complications are these scenarios:

  • “I changed the password for my local account, but only the old password is being taken at the FileVault login screen.”
  • “We’ve lost the password to the only local user account with a Secure Token, so now we can’t enable any other accounts on this Mac for FileVault.”

Usually, this happens because the local account password in question was changed outside of the Users & Groups preference pane in System Preferences and now Secure Token and the account password are out of sync with each other.

Up until the past few days, the only fix I knew of for that situation was to back up the data and wipe the drive. However, it looks like there is a workaround for encrypted Macs which fixes the password problem and sorts out Secure Token in these scenarios. In both cases, a personal recovery key will be needed as the way to authorize the needed changes. For more details, please see below the jump.

Read more…

Unable to enable FileVault on macOS Mojave

February 8, 2019 4 comments

As part of FileVault on Apple File System, Apple introduced a new account attribute called Secure Token. Secure Token can present some interesting complications for Mac admins and among them is this scenario:

“The laptop is decrypted, but we can’t re-enable FileVault now.”

Usually, this happens because the account password was changed outside of the Users & Groups preference pane in System Preferences and now Secure Token and the account password are out of sync with each other.

Up until today, the only fix I knew of for that situation was to back up the data and wipe the drive. However, it looks like there is a workaround that fixes the password problem and sorts out the Secure Token attribute for the account on a decrypted laptop. For more details, please see below the jump.

Read more…

T2, FileVault and brute force attack protection

November 1, 2018 1 comment

Apple recently released an overview document for its new T2 chip, which includes how the new T2 chip-equipped Macs have new protections against brute force attacks. This protection only applies if FileVault is enabled and is similar in concept to how iOS devices set with passcodes are protected against brute force attacks.

On iOS, if an incorrect passcode is entered more than five times, a one minute delay is set.

Img 58462d7da9d03 477x600

After the sixth try, the delay is now five minutes and the delays get longer from there until the device has the 10th wrong passcode entered and the device wipes.

Screen Shot 2018 11 01 at 4 31 50 PM

On Apple iOS devices with a Secure Enclave, those delays are enforced by the Secure Enclave processor. Similarly, the T2 chip-equipped Macs also have a Secure Enclave processor which is managing access attempts and introducing delays.

For Macs with Secure Enclave, the enforcement looks like this:

  • 30 unlock attempts via using the password at the login window or target disk mode
  • 10 unlock attempts via using the password in Recovery Mode
  • 30 unlock attempts for each enabled FileVault recovery mechanism
    • iCloud recovery
    • FileVault personal recovery key
    • FileVault institutional recovery key

The maximum number of unlock attempts is 90, regardless of the mix of methods used. After 90 attempts, the Secure Enclave processor will no longer process any requests to do the following:

  • Unlock the volume
  • Decrypt the volume
  • Verify the password / recovery key

Delays are also imposed on macOS between attempts.

Screen Shot 2018 11 01 at 8 40 50 AM

So what happens after 90 attempts? Does the Mac lock forever and become a paperweight?

After checking with AppleCare Enterprise, the answer is that the Mac will not be a paperweight, but that the Mac’s boot drive will need to be erased before it can be used again. This approach helps make sure that the Mac is still usable, but also ensures that the encrypted data stored on the boot drive is no longer recoverable.

For more information about brute force protection for encrypted iOS and macOS devices, I recommend checking out Apple’s currently available white papers:

Reclaiming drive space by thinning Apple File System snapshot backups

April 7, 2018 15 comments

As part of a recent clean-up of my Apple File System-formatted (APFS) boot drive, I deleted a number of files. However, I noticed that deleting files did not free up nearly as much space as I thought it should. When I investigated, I noticed that my boot drive had a number of Time Machine snapshots stored on it.

Screen Shot 2018 04 07 at 2 04 39 PM

A quick way to reclaim space from a particular snapshot immediately would be to delete the snapshot using the tmutil command line tool, using the command shown below:

tmutil deletelocalsnapshots snapshot-name-here

However, I didn’t want to delete backups if I could avoid it since I might need something stored in one of them. After some research, I was able to find a tmutil command that did what I needed. For more details, please see below the jump:

Read more…

Slides from the “Managing FileVault 2 on macOS High Sierra” Session at MacAD UK 2018 Conference

February 21, 2018 4 comments

For those who wanted a copy of my FileVault 2 management talk at MacAD UK 2018, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/MacADUK2018pdf

Keynote – http://tinyurl.com/MacADUK2018key

Hat tip to the attendee who brought to my attention that fdesetup sync is not supported on encrypted APFS boot drives. I’ve now updated the slides to reflect that it works on macOS High Sierra for HFS+ drives only.

HFS+

Screen Shot 2018 02 21 at 12 54 13 PM

APFS

Screen Shot 2018 02 21 at 1 04 16 PM

%d bloggers like this: