Safe mode is an undervalued tool for dealing with a broad range of problems in macOS. Although not a universal panacea, it has several valuable uses, and can be helpful before having to resort to more time-consuming diagnostic procedures. This article explains how to engage your Mac into Safe mode, what it does, and when you should use it. This is based primarily on macOS Sequoia 15.3.2 running on Apple silicon Macs, but does cover Intel models, and much should apply to recent versions of macOS.

Entering Safe mode

Consider first whether you should disconnect some or all non-essential peripherals. If you’re only intending to use Safe mode to flush caches, or to install an awkward macOS update, that shouldn’t be necessary. When trying to diagnose potential problems with extensions, though, it could be beneficial.

Apple silicon Mac

The Mac must be shut down to begin with. Press its Power button and keep it held in until you see its Recovery options loading. Then select the startup disk you want your Mac to boot from, and hold the Shift key. The button underneath that disk icon will change to read Continue in Safe Mode. Click on that button, and your Mac will restart.

Normally, you’ll be asked to log in twice, and initially, at the upper right of the display, the words Safe Boot will be shown in red.

Intel Mac

All you need do with an Intel Mac is start up (or restart) with the Shift key held down until you see the login window. If you have set a firmware password, you’ll need to remove that in Recovery before trying to start up in Safe mode.

Checking

Once your Mac is running in Safe mode and you’ve logged in, check that it really is in Safe mode by opening System Information. Click on Software at the left, and the line Boot Mode should say Safe rather than Normal.

If you can’t start your Mac up successfully in Safe mode, Recovery is your only option, where you might consider reinstalling macOS.

Leaving Safe mode

To leave Safe mode and return to normal mode, simply restart the Mac.

How is it different?

According to Apple’s current description, Safe mode:

• “Prevents certain software from loading as your Mac starts up. This includes login items and extensions that aren’t required by macOS, and fonts that weren’t installed by macOS.”
• “Performs a basic check of your startup disk, similar to the more comprehensive check performed by the First Aid feature of Disk Utility.”
• “Clears some system caches, including font caches and the kernel cache. These are automatically created again as needed.”

Apple warns that some macOS features may not work when in Safe mode. Those could affect “video capture, graphics performance, file sharing, Wi-Fi, accessibility, audio devices and devices connected via USB, Thunderbolt or FireWire.” In practice these seem to vary according to Mac and macOS, making it hard to know what to expect. Most USB and Thunderbolt storage should still work normally, and Time Machine backups should continue as usual when running in Safe mode.

Blocking extensions and customisations

Booting in Safe mode blocks the loading of all third-party kernel extensions, and may delay the loading of some of those provided in macOS. Specifically, those in the Auxiliary Kernel Collection (AKC) aren’t loaded, and any devices or features relying on them won’t be available. All kernel extensions in the main Kernel Collection appear to be loaded normally. If you suspect that your Mac’s problems could relate to a third-party kernel extension, this makes Safe mode an excellent diagnostic test without having to alter Startup Security for an Apple silicon Mac.

Apple adds to that login items, system extensions (the modern replacement for kernel extensions), and fonts not installed by macOS. These are other common causes of compatibility problems, adding to the value of Safe mode.

Checking the startup disk

Older versions of macOS performed extensive checks of both disks and snapshots using fsck_apfs. Apple discontinued those some years ago, because they extended Safe boot time to periods sometimes exceeding half an hour. Since then, checks performed by fsck_apfs don’t include snapshots, and are quick checks rather than a full check-and-repair. As they’re performed after the Data volume in the active boot volume group has been mounted, they only cover a limited range of volumes: from the active boot volume group, only the Recovery and Update volumes are checked, together with all accessible external volumes. Results are written to the fsck_apfs logs at /var/log/fsck_apfs.log and /var/log/fsck_apfs_error.log, and in entries in the Unified log.

Those checks in Safe mode currently appear identical to those made during a normal boot. Accordingly, if you want to perform checks on your Mac’s current boot volume group, you should do so using Disk Utility or fsck_apfs in Recovery mode. Safe mode is no longer a useful tool for performing disk checks.

Deleting caches

Discovering exactly which caches are emptied or deleted isn’t straightforward. Beyond Apple’s two instances of font caches and the kernel cache (which only applies to Intel Macs), none of the caches used by Launch Services appear to be affected by this. Neither does this appear to include other notable caches and hidden data stores, such as those for QuickLook or Spotlight.

macOS updates

Although not mentioned by Apple, one longstanding use for Safe mode is to download and install macOS updates. This may have become less used since updating was re-engineered for Big Sur, but is always worth bearing in mind. A short visit to Safe mode, lasting just a couple of minutes before restarting in normal user mode, can also fix problems discovered after updating or upgrading macOS; if a normal restart doesn’t sort them out, try Safe mode before calling Apple Support.

Safe mode in Apple silicon Virtual Machines

Safe mode is available when running lightweight virtualisation of macOS on an Apple silicon Mac, provided that the host operating system is Ventura or later, which provides the option to start the VM in Recovery mode. Enable that option before starting the VM, then use the normal procedure to restart in Safe mode. When you shut down that VM, remember to disable starting in Recovery before running the next VM.

Good reasons for Safe mode

• To identify and locate problems with third-party kernel extensions.
• To identify and locate problems with third-party system extensions, fonts, login items, and other user customisations, as a quicker alternative to creating a ‘clean’ user account.
• To download and install macOS updates, when they don’t work in normal mode.
• To fix problems following macOS updates, when a normal restart doesn’t help.
• To clear font and other user caches.
• When there are problems preventing booting in normal mode, short of going to Recovery mode.
• As a generic non-destructive panacea.

If you want a quiet life, just format each external disk in APFS (with or without encryption), and cruise along with plenty of free space on it. For those who need to do different, either getting best performance from a hard disk, or coping with less free space on an SSD, here are some tips that might help.

File system basics

A file system like APFS provides a logical structure for each disk. At the top level it’s divided into one or more partitions that in APFS also serve as containers for its volumes. Partitions are of fixed size, although you can always repartition a disk, a process that macOS will try to perform without losing any of the data in its existing partitions. That isn’t always possible, though: if your 1 TB disk already contains 750 GB, then repartitioning it into two containers of 500 GB each will inevitably lose at least 250 GB of existing data.

All APFS volumes within any given container share the same disk space, and by default each can expand to fill that. However, volumes can also have size limits imposed on them when they’re created. Those can reserve a minimum size for that volume, or limit it to a maximum quota size.

How that logical structure is implemented in terms of physical disk space depends on the storage medium used.

Faster hard disks

Hard disks store data in circular tracks of magnetic material. To store each file requires multiple sectors of those tracks, each of which can contain 512 or 4096 bytes. As the length (circumference) of the tracks is greater as you move away from the centre of the platter towards its edge, but the disk spins at a constant number of revolutions per minute (its angular velocity is constant), it takes a shorter time for sectors at the periphery of the disk to pass under the heads than for those closer to the centre of the platter. The result is that read and write performance also varies according to where files are stored on the disk: they’re faster the further they are from the centre.

This graph shows how read and write speeds change in a typical compact external 2 TB hard disk as data is stored towards the centre of the disk. At the left, the outer third of the disk delivers in excess of 130 MB/s, while the inner third at the right delivers less than 100 MB/s.

You can use this to your advantage. Although you don’t control exactly where file data is stored on a hard disk, you can influence that. Disks normally fill with data from the periphery inwards, so files written first to an otherwise empty disk will normally be written and read faster.

You can help that on a more permanent basis by dividing the disk into two or more partitions (APFS containers), as the first will normally be allocated space on the disk nearest the periphery, so read and write faster than later partitions added nearer the centre. Adding a second container or partition of 20% of the total capacity of the disk won’t cost you much space, but it will ensure that performance doesn’t drop off to little more than half that achieved in the most peripheral 10%.

Reserving free space on SSDs

The firmware in SSDs knows nothing of its logical structure, and for key features manages the whole storage as a single unit. Wear levelling ensures that individual blocks of memory have similar numbers of erase-write cycles, so they age evenly. Consumer SSDs that use dynamic SLC write caches allocate those from across the whole storage, and aren’t confined to partitions. You can thus manage free space to keep sufficient dynamic cache available at a disk level.

One approach is to partition the SSD to reserve a whole container, with its fixed size, to support the needs of the dynamic cache. An alternative is to use volume reserve and quota sizes for the same purpose, within a single container. For example, in a 1 TB SSD with a 100 GB SLC write cache you could either:

• with a single volume, set its quota to 900 GB, or
• add an empty volume with its reserve size set to 100 GB.

Which of these you choose comes down to personal preference, although on boot volume groups you won’t be able to set a quota for its Data volume, and the most practical solution for a boot disk is to add an empty volume with a specified reserve size.

To do this when creating a new volume, click on the Size Options… button and set the quota or reserve.

Summary

• Partition hard disks so that you only use the fastest 80% or so of the disk.
• To reserve space in an SSD for dynamic caching, you can add a second APFS container.
• A simpler and more flexible way to reserve space on SSDs is setting a quota size for a single volume, or adding an empty volume with a reserve size.
• Size options can currently only be set when creating a volume.

Fast SSDs aren’t always fast when writing to them. Even an Apple silicon Mac’s internal SSD can slow alarmingly in the wrong circumstances, as some have recently been keen to demonstrate. This article explains why an expensive SSD normally capable of better than 2.5 GB/s write speed might disappoint, and what you can do to avoid that.

In normal use, there are three potential causes of reduced write speed in an otherwise healthy SSD:

• thermal throttling,
• SLC write cache depletion,
• the need for Trimming and/or housekeeping.

Each of those should only affect write speed, leaving read speed unaffected.

Thermal throttling

Writing data to an SSD generates heat, and writing a lot can cause it to heat up significantly. Internal temperature is monitored by the firmware in the SSD, and when that rises sufficiently, writing to it will be throttled back to a lower speed to stabilise temperature. Some SSDs have proved particularly prone to thermal throttling, among them older versions of the Samsung X5, one of the first full-speed Thunderbolt 3 SSDs.

In testing, thermal throttling can be hard to distinguish from SLC write cache depletion, although thorough tests should reveal its dependence on temperature rather than the mere quantity of data written.

The only solution to thermal throttling is adequate cooling of the SSD. Internal SSDs in Macs with active cooling using fans shouldn’t heat up sufficiently to throttle, provided their air ducts are kept free and they’re used in normal ambient temperatures. Well-designed external enclosures should ensure sufficient cooling using deep fins, although active cooling using small fans remains more controversial.

SLC write cache

To achieve their high storage density, almost all consumer-grade SSDs store multiple bits in each of their memory cells, and most recent products store three in Triple-Level Cell or TLC. Writing all three bits to a single cell takes longer than it would to write them to separate cells, so most TLC SSDs compensate by using caches. Almost all feature a smaller static cache of up to 16 GB, used when writing small amounts of data, and a more substantial dynamic cache borrowed from main storage cells by writing single bits to them as if they were SLC (single-level cell) rather than TLC.

This SLC write cache becomes important when writing large amounts of data to the SSD, as the size of the SLC write cache then determines overall performance. In practice, its size ranges from around 2.5% of total SSD capacity to over 10%. This can’t be measured directly, but can be inferred from measuring speed when writing more data than can be contained in the cache. As it can’t be emptied during full-speed write, once the dynamic cache is full, write speed suddenly falls; for example a Thunderbolt 5 SSD with full-speed write of 5.5 GB/s might fall to 1.4 GB/s when its SLC write cache is full. This is seen in both external and internal SSDs.

To understand the importance of SLC write cache in determining performance, take this real-world example:

• 100 GB is written to a Thunderbolt 5 SSD with an SLC write cache of 50 GB. Although the first half of the 100 GB is written at 5.5 GB/s, the remaining 50 GB is written at 1.4 GB/s because the cache is full. Total time for the whole write is then 44.8 seconds.
• Performing the same to a USB4 SSD with an SLC write cache in excess of 100 GB has a slower maximum rate of 3.7 GB/s, but that’s sustained for the whole 100 GB, which then takes only 27 seconds, 60% of the time of the ‘faster’ SSD.

To predict the effect of SLC write cache size on write performance, you therefore need to know cache size, out-of-cache write speed, and the time required to empty a full cache between writes. I have looked at these on two different SSDs: a recent 2 TB model with a Thunderbolt 5 interface, and a self-assembled USB4 OWC 1M2 enclosure containing a Samsung 990 Pro 2 TB SSD. Other enclosures and SSDs will differ, of course.

The TB5 SSD has a 50 GB SLC write cache, as declared by the vendor and confirmed by testing. With that cache available, write speed is 5.5 GB/s over a TB5 interface, but falls to 1.4 GB/s once the cache is full. It then takes 4 minutes for the cache to be emptied and made available for re-use, allowing write speeds to reach 5.5 GB/s again.

The USB4 SSD has an SLC write cache in excess of 212 GB, as demonstrated by writing a total of 212 GB at its full interface speed of 3.7 GB/s. As the underlying performance of that SSD is claimed to exceed that required to support TB5, putting that SSD in a TB5 enclosure should enable it to comfortably outperform the other SSD.

Two further factors could affect SLC write cache: partitioning and free space.

When you partition a hard disk, that affects the physical layout of data on the disk, a feature sometimes used to ensure that data only uses the outer tracks where reads and writes are fastest. That doesn’t work for SSDs, where the firmware manages storage use, and won’t normally segregate partitions physically. That ensures partitioning into APFS containers doesn’t affect SLC write cache, either in terms of size or performance.

Free space can be extremely important, though. SLC write cache can only use storage that’s not already in use, and if necessary has been erased ready to be re-used. If the SSD only has 100 GB free, then that can’t all be used for cache, so limiting the size that’s available. This is another good reason for the performance of SSDs to suffer when they have little free space available.

Ultimately, to attain high write speeds through SLC write cache, you have to understand the limits of that cache and to work within them. One potential method for effectively doubling the size of that cache might be to use two SSDs in RAID-0, although that opens further questions.

Trim and housekeeping

In principle, Trim appears simple. For example, Wikipedia states: “The TRIM command enables an operating system to notify the SSD of pages which no longer contain valid data. For a file deletion operation, the operating system will mark the file’s sectors as free for new data, then send a TRIM command to the SSD.” A similar explanation is given by vendors like Seagate: “SSD TRIM is a command that optimizes SSDs by informing them which data blocks are no longer in use and can be wiped. When files are deleted, the operating system sends a TRIM command, marking these blocks as free for reuse.”

This rapidly becomes more complicated, though. For a start, the TRIM command for SATA doesn’t exist for NVMe, used by faster SSDs, where its closest substitute is DEALLOCATE. Neither is normally reported in the macOS log, although APFS does report its initial Trim when mounting an SSD. That’s reported for each container, not volume.

What we do know from often bitter experience is that some SSDs progressively slow down with use, a phenomenon most commonly (perhaps only?) seen with SATA drives connected over USB. Those also don’t get an initial Trim by APFS when they’re mounted.

It’s almost impossible to assess whether time required for Trim and housekeeping is likely to have any adverse effect on SSD write speed, provided that sufficient free disk space is maintained to support full-speed writing to the SLC write cache. Neither does there appear to be any need for a container to be remounted to trigger any Trim or housekeeping required to erase deleted storage ready for re-use, provided that macOS considers that SSD supports Trimming.

Getting best write performance from an SSD

• Avoid thermal throttling by keeping the SSD’s temperature controlled. For internal SSDs that needs active cooling by fans; for external SSDs that needs good enclosure design with cooling fins or possibly a fan.
• Keep ample free space on the SSD so the whole of its SLC write cache can be used.
• Limit continuous writes to within the SSD’s SLC write cache size, then allow sufficient time for the cache to empty before writing any more.
• It may be faster to use an SSD with a larger SLC write cache over a slower interface, than one with a smaller cache over a faster interface.
• Avoid SATA SSDs.

I’m grateful to Barry for raising these issues.