File data integrity is one of those topics that never goes away. Maybe that’s because we’ve all suffered in the past, and can’t face a repeat of that awful feeling when an important document can’t be opened because it’s damaged, or crucial data have gone missing. Before considering what we could do prevent that from happening, we must be clear about how it could occur.

We have an important file, and immediately after it was last changed and saved, a SHA256 digest was made of it and saved to that file as an extended attribute, in the way that you can using Dintch, Fintch or cintch. A few days or weeks later we open the file and discover its contents have changed.

Reasons

What could account for that?

One obvious reason is that the file was intentionally changed and saved without updating its digest. Provided there are good backups, we should be able to step back through them to identify when that change occurred, and decide whether it’s plausible that it was performed intentionally. Although the file’s Modified datestamp should coincide with the change seen in its backups, there’s no way of confirming that change was intentional, or even which app was used to write the changed file (with some exceptions, such as PDF).

Exactly the same observations would also be consistent with the file being unintentionally changed, perhaps as a result of a bug in another app or process that resulted in it writing to the wrong file or storage location. The changed digest can only detect the change in file content, and can’t indicate what was responsible. This is a problem common to file systems that automatically update their own records of file digests, as they are unable to tell whether the change is intentional, simply that there has been a change. This also applies to changes resulting from malicious activity.

The one circumstance in which change in contents, hence in digest, wouldn’t necessarily follow a change in the file’s Modified datestamp is when an error occurs in the storage medium. However, this is also the least likely to be encountered in modern storage media without that error being reported.

Errors occurring during transfer to and from storage are detected by CRC or similar checks made as part of the transfer protocol. This is one of the reasons why a transfer bandwidth of 40 Gb/s cannot realise a data transfer rate of 5 GB/s, because part of that bandwidth is used by the error-checking overhead. Once written to a hard disk or SSD, error-correcting codes are used to verify integrity of the data, and are used to detect bad storage blocks.

Out of interest, I’ve been conducting a long-term experiment with 97 image files totalling 60.8 MB stored in my iCloud Drive since 11 April 2020, over five years ago. At least once a year I download them all and check them using Dintch, and so far I haven’t had a single error.

Datestamps

There are dangers inherent in putting trust in file datestamps as markers of change.

In APFS, each file has four different datestamps stored in its attributes:

• create_time, time of creation of that file,
• mod_time, time that file was last modified,
• change_time, time that the file’s attributes including extended attributes were last modified,
• access_time, time that file was last read.

For example, a file with the following datestamps

• create_time 2025-04-18 19:58:48.707+0100
• mod_time 2025-04-18 20:00:56.134+0100
• change_time 2025-07-19 06:59:10.542+0100
• access_time 2025-07-19 06:52:17.504+0100

was created on 18 April this year, last modified a couple of minutes later, last had its attributes changed on 19 July, but was last read 7 minutes before that modification to its attributes.

These can be read using Precize, or in Terminal, but there’s a catch with access_time. APFS has an optional feature, set by volume, determining whether access_time is changed strictly. If that option is set, then every time a file is accessed, whether it’s modified or not, its access_time is updated. However, this defaults to only updating access_time if its current value is earlier than mod_time. I’m not aware of any current method to determine whether the strict access_time is enabled for any APFS volume, and it isn’t shown in Disk Utility.

mod_time can be changed when there has been no change in the file’s data, for example using the Terminal command touch. Any of the times can be altered directly, although that should be very unusual even in malware.

Although attaching a digest to a file as an extended attribute will update its change_time, there are many other reasons for that being changed, including macOS adding or changing quarantine xattrs, the file’s ‘last used date’, and others.

Proposed strategy

1. Tag folders and files whose data integrity you wish to manage.
2. Back them up using a method that preserves those tags, such as Time Machine, or copied to iCloud Drive.
3. Periodically Check their tags to verify their integrity.
4. As soon as possible after any have been intentionally modified and saved, Retag them to ensure their tags are maintained.
5. In the event that any are found to have changed, and no longer match their tag, trace that change back in their backups.

Unlike automatic integrity-checking built into a file system, this will detect all unexpected changes, regardless of whether they are made through the file system, are intentional or unintentional, are malicious, or result from errors in storage media or transmission. Because only intentionally changed files are retagged, this also minimises the size of backups.

It’s commonly claimed that software encryption, as used in APFS Encrypted format, incurs negligible overhead. The last time I looked at that was with Thunderbolt 3 SSDs connected to a Mac Studio M1 Max, when I found that varied according to the SSD. One of the three I tested then did show significant reductions in encrypted write speed, from 2.2 to 1.8 GB/s, but the fastest showed no change from its unencrypted write speed of 2.8 GB/s. This article reports new test results from a Mac mini M4 Pro with faster SSDs, one Thunderbolt 5 and the other USB4, and adds data for computing SHA256 hashes.

These are of particular interest, as not only are the unencrypted transfer speeds for both SSDs significantly higher than Thunderbolt 3, but the host has significantly faster CPU cores.

Two sets of measurements were made on each of the two SSDs:

• Stibium 1.2 running on macOS 15.5 Sequoia was used to measure read and write speeds over randomised sequences of a total of 53 GB in 160 files of 2 MB to 2 GB individual size.
• Stibium was used to measure the single file read speed of a 16.8 GB IPSW file, and Dintch was used to measure the time taken to stream the file in and compute its SHA256 digest, using CryptoKit.

Read and write speeds

Results of the first series of tests showed both SSDs performed as expected when using plain APFS, with read and write speeds of 5.3 GB/s for TB5, and 3.7 GB/s for USB4.

Small reductions in read speed were seen in both SSDs when using APFS Encrypted, to about 98% and 95% of their unencrypted read speed. Although there was a similar small reduction in write speed for USB4, to 97%, that seen in the Thunderbolt 5 SSD was greater, with a fall from 5.3 to 4.7 GB/s (89%). Both sets of tests were repeated for that SSD, allowing ample time for the SLC cache to be emptied after each set of write tests, and results remained essentially the same.

Although write speed to APFS Encrypted for this Thunderbolt 5 SSD remained well above that for USB4, encryption brought a reduction in speed of just over 10%, more than I had anticipated.

Hash computation

SHA256 and SHA512 digests are now used to check file data integrity. Both are computationally intensive, and I have previously reported that reading files of substantial size and computing their digests using CryptoKit proceeds at about 3 GB/s for files stored on the fast internal SSD of a Mac mini M4 Pro.

With the Thunderbolt 5 SSD, a plain file of 16.8 GB was read at 6.5 GB/s, and encrypted at 4.7 GB/s. SHA256 digest computation was performed at 2.6 GB/s from plain APFS, and 2.2 GB/s from APFS Encrypted, both well below that from the internal SSD, and less than half the speed of just reading the file.

Although the USB4 SSD was inevitably slower on the read tests, at 3.8 GB/s, encryption had little effect, at 3.7 GB/s. SHA256 digest computation was, if anything, faster than with Thunderbolt 5, at 2.8 GB/s plain, and 2.7 GB/s encrypted.

Conclusions

Although there may well be differences with other Thunderbolt 5 and USB4 SSDs, and more extensive results would be helpful:

• Whether plain or encrypted APFS, Thunderbolt 5 SSDs are substantially faster than USB4.
• Encryption can result in significantly lower write speeds on some Thunderbolt 5 SSDs.
• Otherwise, encryption has only small effects on read and write speeds.
• Computation of SHA256 digests is significantly slower than encryption, and ranges between 2.2-2.8 GB/s on larger files.
• This suggests that, even in faster M4 chips, CPU performance limits the speed of software encryption, and even more so for SHA256 digest computation.

This week I have another group of four little utilities whose windows have been overhauled, and have new app icons to meet the requirements of macOS Tahoe. Each of these new versions requires macOS Big Sur or later.

Finder aliases

If you have old Finder aliases that need to be checked and repaired, Alifix will do that job with you. Use it to scan a folder containing those aliases, and it will warn you which can’t be resolved any longer, and can rewrite those that need to be updated.

Alifix version 1.4 is now available from here: alifix14
and from its Product Page. As it seldom needs updating, it doesn’t use the auto-update mechanism.

APFS sparse and clone files

As you can tell by its name, Sparsity started off as a means of creating APFS sparse files for test purposes. In addition to that, it has a valuable scanning feature that will detect and report details of all sparse, clone and purgeable files in a selected volume or folder. Information reported includes both the nominal and actual size of each file, so you can see which sparse files are saving the most space on disk.

Sparsity version 1.4 is now available from here: sparsity14
and from its Product Page. It too doesn’t use auto-update.

UTI file types

Give UTIutility a filename extension and it will tell you its Uniform Type Indicator (UTI, also UTType), traditional Mac OSType, MIME type, Pasteboard type, and a list of UTIs it conforms to. You can also find the same information from those other properties. This too has a crawler that will search through a volume or folder and compile a list of all the UTIs it encounters there. Its Help book contains an extensive reference to UTIs to help you get the most out of them.

UTIutility version 1.4 is now available from here: utiutil14
and from its Product Page. It doesn’t use auto-update.

Natural language

For many years, macOS has had built-in features to handle and parse natural languages including French, Spanish and German. Nalaprop uses these features to analyse text files, or text pasted into the left view in its main window. That text can then be parsed by downloadable linguistics modules supplied by Apple, and each word displayed in colour according to that word’s part of speech or grammatical type. From that it can automatically construct dictionaries or concordances of words used in that text, arranged by part of speech, and giving word frequency for each.

Nalaprop comes with a multilingual demonstration file to show how well it copes with language transitions.

Here it has parsed and coloured the text in the middle according to part of speech, for two languages, English and French. To the right of those is the dictionary it has compiled, ending verbs and starting the list of nouns. At the far right is a colour key for parts of speech.

In this demonstration, Charles Dickens’ novel David Copperfield has been parsed, a total of nearly 360,000 words. Currently such large documents are analysed in the main thread, so you’re likely to see a spinning beachball during parsing, but can still switch freely to other apps when that’s taking place. Those with Apple silicon Macs will see that analysis is performed in a single thread running on one P core, so all the other P cores remain free to run other tasks. I was hoping to use different threads for this, but it proved too complicated to incorporate in this particular version.

Nalaprop version 1.4 is now available from here: nalaprop14
from its Product Page, and via its auto-update mechanism.

Enjoy!

Here are the 21 icons for those of my apps so far ported to be compatible with Tahoe.

You don’t have to collect all in the series, though.

We rely on FileVault and APFS to protect our secrets by encrypting the volumes containing our documents and data. How they do that is a mystery to many, and raises important questions such as the role our passwords play, and how recovery keys work. This article attempts to demystify them.

Naïve encryption

A simple scheme to encrypt a disk or volume might be to take the user password, somehow turn it into a key suitable for the encryption method to be used, and employ that to encrypt and decrypt the data as it’s transferred between disk storage and memory.

There are lots of weaknesses and difficulties with that. Even using a ‘robust’ user password, it’s not going to be memorable, sufficiently long or hard to crack, and there’s no scope for recovery if that password is lost or forgotten.

FileVault base encryption

In Macs with T2 or Apple silicon chips when FileVault is disabled, everything in the Data volume stored on their internal SSD is still encrypted, but without any user password. This is performed in the Secure Enclave, which both handles the keys and performs the encryption/decryption. That ensures the keys used never leave the Secure Enclave, so are as well-protected as possible.

Generating the key used to encrypt the volume, the Volume Encryption Key or VEK, requires two huge numbers, a hardware key unique to that Mac, and the xART key generated by the Secure Enclave as a random number. The former ties the encryption to that Mac, and the latter ensures that an intruder can’t repeat generation of the same VEK even if it does know the hardware key. When you use Erase All Content and Settings (EACAS), the VEK is securely erased, rendering the encrypted data inaccessible, and there’s no means to either recover or recreate it.

This scheme lets the Mac automatically unlock decryption, but doesn’t put that in the control of the user, who therefore needs to enable FileVault to get full protection.

FileVault full encryption

Rather than trying to incorporate a user password or other key into the VEK, like many other encryption systems FileVault does this by encrypting the VEK using a Key Encryption Key or KEK, a process known as wrapping.

When you enter your FileVault password, that’s passed to the Secure Enclave, where it’s combined with the hardware key to generate the KEK, and that’s then used together with hardware and xART keys to decrypt or unwrap the VEK used for decryption/encryption.

This has several important benefits. As the KEK can be changed without producing a new VEK, the user password can be changed without the contents of the protected volume having to be fully decrypted and encrypted again. It’s also possible to generate multiple KEKs to support the use of recovery keys that can be used to unlock the VEK when the user’s password is lost or forgotten. Institutional keys can be created to unlock multiple KEKs and VEKs where an organisation might need access to protected storage in multiple Macs.

APFS encryption

True FileVault requires all keys to be stored in the Secure Enclave, and never released outside it. Intel Macs without T2 chips, and other protected volumes such as those on external storage can’t use that, and in the case of removable storage need an alternative that stays on the disk. For that, APFS uses the AES Key Wrap Specification in RFC 3394, using a secret such as a password to maintain confidentiality of every key.

APFS also uses separate VEKs and KEKs, so enabling the use of multiple KEKs for a single VEK, and the potential to change a KEK without having to decrypt and re-encrypt the whole volume, as in FileVault. In APFS, VEKs and KEKs are stored in and accessed from Keybags associated with both containers and volumes. The Container Keybag contains wrapped VEKs for each encrypted volume within that container, together with the location of each encrypted volume’s keybag. The Volume Keybag contains one or more wrapped KEKs for that volume, and an optional passphrase hint. These are shown in the diagram below.

Apple’s documentation refers to several secrets that can be used to wrap a KEK, including a user password, an individual recovery key, an institutional recovery key, and an unspecified mechanism implemented through iCloud. Currently, for normal software encryption in APFS, only two of those appear accessible: a user password is supported in both Disk Utility and diskutil‘s apfs verb, while diskutil also supports use of an institutional recovery key through its -recoverykeychain options. Individual and iCloud recovery keys only appear available when using FileVault, in this case implemented in software, either on Intel Macs without a T2 chip, or on all Macs when encrypting an external volume.

Because keybags are stored on the disk containing the encrypted volume, if the disk is connected to another Mac, when macOS tries to mount that volume, the user will be prompted to enter its password, and can then gain access to its contents. When FileVault is used to protect a Data volume on the internal SSD of a T2 or Apple silicon Mac, that volume can only be unlocked through the Secure Enclave of that Mac, and it isn’t possible to unlock it from another Mac (that’s also true when FileVault hasn’t been enabled on that volume).

Volume structure of internal startup disks has grown increasingly complex during the transition from Intel to Apple silicon Macs. There also seems to be little information on iOS and iPadOS to compare against. This article briefly reviews structures of macOS 15 Sequoia on Apple silicon, iOS 18 and iPadOS 18.

Information for macOS is derived from the diskutil command tool, and from APFS entries in the log when booting a Mac mini M4 Pro in macOS 15.5. That for iOS is drawn from APFS entries in the log when booting an iPhone 15 Pro in iOS 18.5. That for iPadOS is drawn from APFS entries in the log when booting an iPad Pro 11-inch (4th generation)(Wi-Fi) in iPadOS 18.5. All three had Apple Intelligence enabled prior to booting. iOS and iPadOS logs were obtained from sysdiagnoses, and all logs were read using LogUI.

macOS 15 (Apple silicon)

The boot volume group consists of six volumes in a single container (partition). Two other containers are normally hidden from the user:

• the first container of around 524 MB is reserved for preboot and secure boot support.
• another container of about 5.4 GB is used for fallback recovery frOS, and in Big Sur was the primary recovery system, until the introduction of paired recovery volumes in macOS 12 Monterey.

The boot volume group contains:

• System, left unmounted after booting from its Signed System Volume (SSV) snapshot;
• Data, the only encrypted volume in the group, with numerous cryptexes grafted into it, and firmlinked to the SSV at multiple points;
• paired, primary Recovery, containing a disk image of the Recovery system;
• VM, the backing store for virtual memory;
• Preboot, for early stages in the secure boot process, with cryptexes grafted into it;
• Update, used as a working volume for macOS updates.

There are two groups of cryptexes grafted onto those volumes:

• system cryptexes, including the large SystemCryptex or os.dmg of about 4.3 GB mainly containing dyld caches, and the smaller AppCryptex or app.dmg containing Safari and supporting components;
• PFK volumes containing support components for Apple Intelligence features. These are numerous, and some are listed in the Appendix at the end.

If you’re wondering what a PFK volume might be, so am I. But this is what Google’s AI had to say: “Mac PFK” likely refers to a combination of MAC knives and Practical Fishkeeping (PFK) magazine. MAC knives are known for their high-quality, sharp blades and are popular among chefs and home cooks. Practical Fishkeeping is a magazine focused on fishkeeping, covering various aspects of the hobby.

These are summarised, without the help of Practical Fishkeeping, in this diagram.

iPadOS 18

In contrast to macOS since Big Sur, iPadOS and iOS only appear to have two containers (partitions) on their internal storage. The first is presumed to be similar in purpose to that in macOS, in supporting preboot and secure boot, although there is a xART volume in the boot volume group. In iPadOS, this container is smaller, at around 367 MB.

The boot volume group contains a slightly different range of volumes:

• there is no Recovery volume;
• there is no VM volume, as iPadOS doesn’t ordinarily support swapping/paging, although M-series models can in certain circumstances;
• User, a second encrypted volume, appears unique to iPadOS;
• xART and Hardware volumes are additional.

Cryptexes appear similar, with both system cryptexes and PFK volumes.

These are summarised below.

iOS 18

This is similar to iPadOS, with a first container/partition of around 351 MB, and the following differences in the boot volume group:

• there is no User volume, and no Update volume;
• Baseband Data is additional.

Cryptexes appear similar, with both system cryptexes and PFK volumes.

These are summarised below.

Conclusions

• Volume structure of internal startup disks differs considerably between macOS, iPadOS and iOS.
• As would be expected, iPadOS and iOS are most similar, but even they have substantial differences.
• They each run their systems from a Signed System Volume firmlinked to an encrypted Data volume.
• They each graft on two sets of cryptexes, one supplementing the system with dyld caches and Safari, the other providing components for AI.
• There are now at least 24 cryptexes used to support AI.

I welcome corrections and explanations, please.

Appendix: Some PFK volumes from cryptexes

• UC_FM_LANGUAGE_INSTRUCT_300M_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_300M_BAUC_FM_LANGUAGE_INSTRUCT_300M_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_DRAFTS_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_CONCISE_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAIL_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAIL_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_PROFESSIONAL_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_SUMMARIZATION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_EVENT_EXTRACTION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_PROOFREADING_REVIEW_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_HANDWRITING_SYNTHESIS_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_EVENT_EXTRACTION_MULTILINGUAL_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MESSAGES_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_AUTONAMING_MESSAGES_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_URGENCY_CLASSIFICATION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_FRIENDLY_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_HANDWRITING_SYNTHESIS_MULTILINGUAL_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_VISUAL_IMAGE_DIFFUSION_V1_BASE_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_PERSON_EXTRACTION_MULTILINGUAL_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• SECUREPKITRUSTSTOREASSETS_SECUREPKITRUSTSTORE_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_PERSON_EXTRACTION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAGIC_REWRITE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_IF_PLANNER_NLROUTER_BASE_EN_GENERIC_H14G_Cryptex.dmg

Source: iPadOS 18.5, configured with AI enabled for British English.

If you used a Mac before 2017, you’ll be accustomed to running First Aid in Disk Utility as part of your routine housekeeping. Now all recent versions of macOS start up from a boot volume group in APFS, you might wonder whether that practice is still needed, and how it should be done.

Reliability of APFS

Like any file system, APFS can still acquire errors, but it’s designed to be as reliable as possible, particularly when used on SSDs.

Its file system uses Fletcher 64 checksums to ensure its integrity, although it doesn’t use checksums or hashes to check the integrity of file data. When each partition (container) is mounted, APFS finds the superblock with the most recent transaction identifier, and checks that it and its contents are valid. Each volume then has a quick check run by fsck_apfs (called by Disk Utility to perform First Aid) before it’s mounted. APFS also performs a Trim on each volume during the mount process.

APFS was designed to be the file system for Apple’s devices, including iPhones, where self-maintenance and reliability are essential, and users can’t perform routine maintenance on the file system.

Boot volume group

All Macs now start up from a boot volume group, consisting of the Signed System Volume (SSV), and a conjoined Data volume. Since Big Sur, the SSV is a read-only snapshot of the system that’s sealed using a tree of hashes to verify the integrity of its entire contents. As a snapshot, it’s read-only, and its hierarchy of hashes is checked progressively as its contents are accessed. Any error found in its hashes will normally result in the volume being reinstalled and a fresh snapshot made.

Although Disk Utility will attempt to check the Data volume while it’s still ‘live’, you should avoid that whenever possible. If you want to run First Aid or fsck_apfs on the Data volume, then it’s best to do so in Recovery mode, so the volume can be properly unmounted for checking. Safe mode is no substitute, though, neither does Safe mode perform any more thorough checks than normal user mode.

Time Machine backups

All Time Machine backups are made as read-only snapshots. Local snapshots are also made at the same time to each volume being backed up, and those too are read-only. Local snapshots are routinely deleted when they’re 24 hours old, although you can delete them manually before then. As Time Machine uses the most recent local snapshot when making the next of its backups, avoid deleting that if possible.

Indications for First Aid

The most reliable indicator of a problem with a file system is an alert reporting a file system error. Severe errors may be responsible for a kernel panic, although that’s now unusual unless a disk is in the process of failing altogether.

Running First Aid is no longer recommended as a routine practice in the way that it was when using HFS+. macOS updates are performed with the Data volume unmounted for much of the time. They update the files on the System volume (which is unmounted during normal running), make a snapshot of it, and build the hash tree to verify its contents. When that’s completed, the top-level hash is hashed again to produce the SSV’s signature, which is then compared with that set for the specific version of macOS. If there is any discrepancy, macOS has to be reinstalled and the process of creating the SSV repeated.

Warnings or errors?

Both First Aid and fsck_apfs may report warnings as well as errors, which are distinguished by the term given in the report. Warnings are almost invariably benign, and not a call to take any action. For example
warning: inode (id 1234567): Resource Fork xattr is missing or empty for compressed file
doesn’t normally require any repair, as it’s a warning of a condition that may be normal.

First Aid may refer to performing “deferred repairs”; those appear to be repairs to errors that APFS has already decided it needs to make, but did’t at the time. Sometimes they and other errors require “full space verification”, normally performed when you run First Aid on that container rather than the volume. In that case, when you check and repair the container, any error should be fixed.

Sequence

Apple recommends that check and repair using First Aid or fsck_apfs is performed first on each volume within a container (partition), then on the container itself, and finally on the disk. This sequence may differ from that used on HFS+ and other file systems.

Run First Aid on the Data volume

If you have evidence suggesting that there’s an error affecting your Mac’s Data volume, start it up in Recovery mode, select Options, click Continue underneath it then select Disk Utility in the window and click Continue.

Set its View tool to Show All Devices, then select the Data or Macintosh HD – Data volume in the boot group you want to check, and click First Aid.

Once that’s complete, select the container above that Data volume, and click First Aid.

Finally select the disk above that container, and click First Aid.

When you need to run First Aid on an external disk, you should be able to follow the same sequence when running in normal mode, rather than in Recovery. If First Aid complains of an error because one or more volumes are mounted, select the volume in the list at the left and click the Unmount tool. Once that volume has unmounted, select it again, and try First Aid. If that also fails for the same reason, select the disk itself, click on Unmount and then First Aid again. If you don’t have any joy, start your Mac up in Recovery and work from there instead.

Summary

• Run First Aid in Disk Utility, or fsck_apfs, when there has been an error or incident that makes you suspect there may be an error in the file system.
• Check and repair volumes in your current boot group in Recovery.
• Set View to Show All Devices so you can see containers.
• Run First Aid on volumes first, then containers, then disks last of all.
• If any fail because they’re mounted, select the volume or disk, unmount it, and try again.
• Warnings aren’t errors, and are likely to be normal.