Most problems with Spotlight are assumed to be the result of it failing to index correctly. I’ve recently detailed how you can diagnose those, and explained why blindly rebuilding its indexes is often a waste of time and effort. Problems that aren’t the result of failed indexing are harder to diagnose and fix. This article describes one approach that doesn’t appear to have been used previously: restarting Spotlight.
Relaunch Spotlight
It turns out that it’s quick and easy to restart Spotlight without having to log out and back in. Open the Finder’s Settings, select the Advanced tool and toggle Show all filename extensions off and on (or on and off). While you’re doing that, watch the Spotlight icon at the right end of the menu bar, and you’ll see it vanish and reappear as Spotlight is relaunched.
This may seem strange, but is clear from the log entries. 0.727612 Finder sendAction:
marks when the checkbox was toggled by the user. Within 0.01 second, Spotlight announces it’s relaunching 0.733710 com.apple.spotlight Relaunching Spotlight to respond to user show extensions change.
Then follow log entries detailing Spotlight being shut down 0.741258 gui/501/com.apple.Spotlight [1183] exited due to exit(255), ran for 60931ms
0.741307 gui/501 [100019] service inactive: com.apple.Spotlight
0.742190 com.apple.launchservices DEATH: Received pid death for 1183, found application App:"Spotlight" asn:0x0-39039 pid:1183 refs=5 @ 0x8d0ef9080 in session "LSSession:id=100019 @ 0x102a996e0 Apps:43 ", which was not a LS launched process, so removing it.
This also takes out the StocksKit service, responsible for providing currency conversion rates and more 0.743045 pid/1183 [Spotlight] removing active service: com.apple.StocksKitService
and the Spotlight icon is removed from the menu bar 0.744222 com.apple.controlcenter Removing ephemeral displayable instance DisplayableId(4C3DBA87) from menu bar. No corresponding host (bid:com.apple.Spotlight-Item-0)
Almost immediately, a new Spotlight service is started up to replace that 0.751631 gui/501/com.apple.Spotlight [1185] service state: running
0.751651 gui/501/com.apple.Spotlight [1185] Successfully spawned Spotlight[1185] because semaphore
and its preferences are loaded ready 0.774661 Loading Preferences From User CFPrefsD
0.784283 com.apple.runningboard [osservice<com.apple.Spotlight(501)>:1185] reported to RB as running
following which there are many entries detailing Spotlight services being reinstated, and StocksKit reloading currency conversion rates.
Quite why Spotlight needs to be relaunched when you change the Show all filename extensions setting in the Finder is a mystery, but the same appears to happen in all versions of macOS from Ventura and probably earlier.
Errors
The reason I discovered this is that Adam Engst of TidBITS informed me that he sees an error message when that Finder setting is changed if Spotlight settings are also open. I’ve been unable to reproduce that, but think I can explain it, and why restarting Spotlight can be useful.
When Spotlight starts up again, it may encounter a problem with a Spotlight extension, something you’re unlikely to come across when logging in normally. That can be aided when Spotlight settings are open. If you see an error, open General settings, and Login Items & Extensions within that. At the foot of that, list Extensions By Category rather than By App, and you’ll see at the very end of the list the item named Spotlight.
Click on the ⓘ by that and review the Spotlight extensions your Mac can load. Turn off those you don’t need, click Done, then restart Spotlight again using the Finder’s Settings. That may help you to identify an extension that needs to be updated.
Summary
You can restart Spotlight by toggling Show all filename extensions in the Finder’s Settings.
This could resolve Spotlight problems that aren’t the result of indexing failure.
This could also help you identify incompatible Spotlight extensions.
Let me know if you find this useful, or just a curious quirk.
Spotlight local search problems are common, and are all too often tackled blindly by forcing a volume’s indexes to be rebuilt. Although that can sometimes resolve the problem, without knowing its cause, it can just waste time and effort. In some cases rebuilding the indexes can worsen the problem, at least temporarily. This article explains how to use SpotTest and other tools to perform systematic testing and arrive at a diagnosis before hazarding a guess at its treatment.
1. Setting up
Before going any further, check that Spotlight settings are in order, and don’t exclude the volume or folder you’re trying to search, or the document type you’re looking for. In Spotlight settings,
check all Results from System are turned on, particularly Files and Folders,
click on Search Privacy… and remove any locations you want to include in search.
Then open Activity Monitor and watch its CPU % listing to verify that Spotlight isn’t currently in the process of reindexing or performing other maintenance to its indexes. If it is, delay testing until those have completed. Searching using Spotlight while it’s actively working on its indexes will give odd results, or none at all.
If you’re going to use SpotTest on any location with privacy control, such as your Home Documents folder or an external disk, add the app to the Full Disk Access list in Privacy & Security settings, before opening it.
2. Home folder test
Even if your interest is in a different volume, perform a basic test of a new test folder in your current Home folder, to establish a baseline and confirm that Spotlight is working there.
Open SpotTest and set it to defaults, with a Term of cattle, a Scope of [Home], and both Search Keywords and Search EXIF ticked.
Click the Create Tests tool (the leftmost of the tools) to create the folder of test files at the top level of your Home folder. Make a note of the time to the second that you do this.
About 10 seconds after that, click either the Run NSMetadata test or Run mdfind test tool. You should then see a list of files found, including those in the test folder ~/0_SpotTestFiles, including A, B, C, D, E, F, G, K, L, M.
If you don’t see those listed, open Mints and use the Log Window button in its Spotlight section to obtain a log extract from the time the test files were created, or use LogUI to do the same. You’ll then need to look at that log extract to see if there are clues as to why indexing didn’t take place in that period.
Leave the test folder where it is, and anything from 1 hour to 5 days later, repeat the search using either or both of those tools. Once additional indexing has been undertaken:
NSMetadata should now find A, B, C, D, E, F, G, I, K, L, M but not H
mdfind should now find A, B, C, D, E, F, G, H, I, K, L, M.
I is found using Live Text, and H by Visual Look Up, the latter only being found by the mdfind search.
These tests have demonstrated:
mdworker and mds indexing of files supported by system mdimporters;
delayed background mediaanalysisd image analysis and mds indexing of Live Text and Visual Look Up content.
To match test files with their importers, click the Check importers tool. Note that file L doesn’t use a plugin, and N uses a plugin but can’t be found because the search term is inside an image in the PDF document, which currently isn’t recoverable content.
3. Metadata indexing
If that test isn’t fully successful, or you’re uncertain whether indexing is complete, inspect the metadata of the test files. Open a Finder window on the contents of ~/0_SpotTestFiles, set it to Column View, and widen the window to provide a suitable Preview pane within it. Select each of three files in turn and confirm their metadata are shown correctly. To inspect all available metadata, click on any Show More text.
SpotTestC.pdf will have different datestamps, but the seven fields of metadata below those should be identical to those shown above.
SpotTestK.jpg will also have different datestamps, but the five fields below should be identical to those above.
SpotTestM.txt should include a final line of Keywords one, cattle, three.
You can also check all indexed metadata for those files in Terminal using the commands mdls ~/0_SpotTestFiles/SpotTestC.pdf
mdls ~/0_SpotTestFiles/SpotTestK.jpg
mdls ~/0_SpotTestFiles/SpotTestM.txt
Missing metadata on those three files demonstrates that the test folder hasn’t been indexed correctly. You can try restarting your Mac, leaving it a few minutes to update its Spotlight indexes, then repeating the tests using SpotTest.
4. Custom mdimporter
Many apps come with their own custom mdimporter that provides Spotlight indexing support for document types not supported by macOS. In the past, these were normally installed in /Library/Spotlight, but more recent apps typically keep them inside the app bundle in Library/Spotlight. These can be tested easily.
Create and save one of those custom document types, so that it contains the word cattle in a way that should be searchable by Spotlight. Copy that document to the ~/0_SpotTestFiles folder, wait about 10 seconds, then repeat the test search. You may well notice that NSMetadata search doesn’t find your custom test document, but mdfind does, because of the difference in the search criteria they use.
You should also click the Check importers tool to check that the correct mdimporter was recognised and used for the custom document type.
5. Volume test
If Spotlight works correctly with the test folder in your Home folder, you may wish to progress to testing a different volume or location. Having created its test folder in ~/0_SpotTestFiles, copy that to the other location. Before you change the Scope of the search, click on the button to list available volumes, then select the volume containing the copied test folder in the Scope menu.
When you perform the two types of search on that volume, the same rules should apply as to which will be found. Note though that finding files I and H can take much longer, or they may not appear at all.
6. Search term test
When you’re confident that a search term of cattle can be found reliably, you may wish to extend your testing to other terms. Take care when choosing custom terms, as you want to be confident that they should be found, but not in such numbers that the results are overwhelming. You will also need to create your own test files containing the custom term.
Diagnosis
SpotTest can thus provide key information on:
Delay or absence of find following creation of test files. If no indexing activity is seen in the log, that indicates indexing failure. If the test files are indexed promptly, it indicates search failure.
Delay or absence in finding files H and I, indicating an indexing failure.
Failure of a custom mdimporter to index a custom document type.
Failure to index another volume.
Those should fit in with the overall scheme used by Spotlight, as shown below.
Diagnosing problems using the Unified log is a complicated business that requires understanding, insight, experience and a systematic approach. As few of us feel competent to wade through thousands of log entries trying to spot where things go wrong, this might seem an ideal opportunity for the use of AI. I’m very grateful to one of our regular readers for the opportunity to demonstrate how Claude coped with diagnosing a troublesome problem they’ve been having with the Clock app in Tahoe.
Signs and symptoms
When you’re diagnosing any problem, you should start with a clear account of its signs and symptoms before even thinking of resorting to the log. A good physician may take an hour or more obtaining a full history and examining a patient before they start thinking about performing any special investigations. Even though signs and symptoms may not lead you to a diagnosis, they should help you direct your investigations to best effect.
In this case, although the Clock app is launching, when displaying some views the content is missing. We therefore agreed to capture the log from the moment of launch from the Finder until one of the problematic views displayed. That’s easy to achieve by double-clicking the app when the menu bar clock has just turned to display 00 seconds, then checking the time again when the view has been displayed. Add a couple of seconds to the latter to determine the period to view in LogUI.
What’s normal?
Recognising what’s abnormal in the log is only possible if you know what the normal looks like. It’s often perfectly normal to see error messages, but knowing which are relevant is more difficult. In this case, I cheated and obtained a matching log extract from launching the Clock app on another Mac running the same version of Tahoe, making it simple to compare the two.
An interesting exercise for the reader is to submit a perfectly normal log extract to AI, with a vague description like “problems starting the app”, and seeing if it reports that as being normal. I doubt that it would.
Preparing a log extract for submission to AI
LogUI can provide log extracts saved to Rich Text Format, preserving the entry fields, although I doubt whether any AI will be able to interpret those correctly. Perhaps the best route is to save the extract in RTF, and save that in turn as plain text. A longer way round is to:
Save the whole extract as a JSON file, to preserve the whole record.
Use the Search tool to display the entries you want to submit for analysis.
Click on the Reduce tool to remove the unwanted entries.
Save the remaining entries in Rich Text, then save that in plain text format.
That also allows you to submit a shorter extract.
Claude’s report
AIs like Claude are thoroughly professional in their reporting, even when they’re utterly incorrect. In this case, Claude’s report is headed Complete Analysis of the Problem, and appears a confident and detailed assessment presented logically. It first establishes:
The App DOES Launch Successfully
Main Issue: Continuous Assertion Invalidation
Infinite State Loop
Critical Errors Identified
supporting those with digested “quotations” from the log, although in fact most of them are rendered in Claude’s words, not those in the log entries themselves.
It then leaps on to give the Final Diagnosis that the Clock app:
Fails to maintain the assertions necessary to remain active
The system continuously invalidates its resource requests.
Those are embellished with appropriate and emoji.
Following those conclusions, it cites what it terms Key Log Evidence in support of that diagnosis. Among those are the following.
Critical Error at Launch
For this, it quotes part of the message from 00.968273 error com.apple.runningboard [app[application.com.apple.clock.1152921500311884024.1152921500311884029(501)]:1921] Memorystatus failed with unexpected error: Invalid argument (22)
and a similar entry.
However, it doesn’t point out that those are rapidly followed by 00.969966 com.apple.runningboard [app[application.com.apple.clock.1152921500311884024.1152921500311884029(501)]:1921] set Memory Limits to Soft Inactive (800)
00.970684 com.apple.launchservices LAUNCH: Successful launched 0x0-0x3b03b pid=1921 com.apple.clock '[private]'
which would appear to contradict this being a “critical error”.
Kernel Warning
Claude’s report next misquotes one of the log entries as reporting Clock[19237] triggered unmask of range (1 of 16384:0000->0x1ce000000 of DVLD shared region in VM map 0x5c946dd8d4c72dbbf
when in fact the full entry reads 10.891949 kernel Clock[19237] triggered unnest of range 0x1e8000000->0x1ea000000 of DYLD shared region in VM map 0x5c946da0d472dbbf. While not abnormal for debuggers, this increases system memory footprint until the target exits.
It gives no reason for changing unnest to unmask,DYLD (which makes sense) to DVLD (which is nonsense), or changing the range given.
For interest, I used LogUI’s Gloss feature to submit that entry to ChatGPT for its explanation: This log entry is a system notice from the kernel indicating that a portion of the DYLD shared region in the virtual memory (VM) map has been unnested. […] In short: The macOS kernel is reporting that the process Clock caused a part of the shared dynamic library cache to become private memory. This is expected behaviour when certain debugging or memory operations occur, but it will temporarily use more RAM until the process exits.
Continuous Assertion Cycle and Scene Management Loop
Claude then claims that the perfectly normal entries made by RunningBoard and FrontBoard demonstrate a continuous assertion cycle and scene management loop. Anyone who has read my account of RunningBoard would realise that is a misreading of what is both common and normal.
Claude’s Possible Solutions
Nearing the end of the report, Claude recommends four possible solutions:
Reset system permissions: sudo tccutil reset All com.apple.clock
Rebuild launch services cache: /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user
Verify system integrity: sudo /usr/libexec/repair_packages --verify --standard-pkgs
If everything fails: This could be a specific bug in macOS Tahoe with the Clock app that requires a system update.
The first is misleading, as TCC has nothing to do with system permissions, but privacy controls. Although Claude has made no comments at all on entries by TCC, I have checked through those thoroughly and there’s no evidence of any problem with that subsystem. The command recommended isn’t likely to do anything useful, either.
Despite Claude having provided no evidence of any problem with LaunchServices, its second solution is to perform a full reset of the LaunchServices registry (not cache), although I’m not sure the command given is correct for that. This used to be a popular panacea in the past, but is now more trouble than it’s likely to be worth. The last time I reviewed this for Sequoia, I wrote:
“Running either of those in recent versions of macOS including Sequoia is likely to wreak havoc, though. While this appears to be effective with the Open With… list, its effects on System Settings can be catastrophic. This can remove its entire contents, and even blow the wallpaper away. Normal function should start to return after restarting the Mac, but even then problems can persist.”
Yet Claude gives no warnings of any adverse effects.
The third solution given is the most puzzling. repair_packages was used to repair System permissions in versions of macOS up to El Capitan. It hasn’t been used since, makes no sense at all in Tahoe with SIP and the SSV, and that command no longer exists anyway. I find it surprising that Claude should be recommending a course of action from ten years ago.
The final recommendation is manifestly ineffective, as this problem has persisted across updates from 26.0 to 26.0.1 and now 26.1.
Nowhere does Claude recommend the obvious course of action to contact Apple Support.
Claude’s Summary
The slick summary rounding off Claude’s Complete Analysis of the Problem states confidently that its root cause “appears to be either:”
“A system-level bug in macOS Tahoe’s memory status handling for this specific app”
“Corruption in the app’s entitlements or sandbox configuration”
“A conflict between the app’s resource requirements and what the system is willing to grant”
with the parting comment: The error code 22 (EINVAL – Invalid argument) in the memorystatus call suggests the app is requesting memory limits or priority settings that the kernel considers invalid for its configuration.
None of those comments is supported in reality, nor by the evidence in the log extract.
My final test was to compare the log entries that Claude singled out as being diagnostic of the problem it has ‘completely analysed’, with those from my Mac mini M4 Pro, whose Clock app works perfectly. You won’t be surprised to learn that, in those respects at least, the two logs are identical. For the avoidance of doubt, that includes the “Kernel Warning” and “Critical Error at Launch” entries that Claude considered diagnostic.
My Summary
When presented with a log extract, Claude misidentified and misread log entries, and introduced errors in reporting what it claimed were the most important diagnostic entries. Its recommended solutions were ineffective, unwise, or a decade out of date. Neither did it give any warnings for their adverse effects, or recommend contacting Apple Support.
This doesn’t say that AI can’t help interpret macOS Unified log entries, and can’t do better in the future. But I hope it demonstrates the reality of what it will do today.
Postscript
Following up on Claude’s suggested solutions, I can confirm that the suggested tccutil command is ineffective, and that Tahoe has removed the -kill option from lsregister “because it was dangerous and no longer useful”. As the third solution was removed years ago, that leaves only the last of its suggestions that is valid.
For much of the last 25 years, macOS has had ill-defined and pervasive problems that have often been attributed to incorrect permissions in various parts of the file system. As a result, one of the common panaceas has been to repair those permissions, using procedures that have changed over those years.
Repair disk permissions
Until the introduction of System Integrity Protection (SIP) in 10.11 El Capitan, these problems generally resulted from files within the system acquiring incorrect permissions. To address this, Disk Utility had a feature to check and repair permissions of all major parts of the system, based on information contained in BoM files for system updates and installations. Repairing permissions in this way became one of the main panaceas in those older versions.
Although primarily intended to deliver better security protection, one of the benefits of SIP was that it largely prevented system files from gaining incorrect permissions, and the feature to repair them was removed from Disk Utility. In any case, because of SIP it was no longer possible for Disk Utility to change the permissions of files that were protected by SIP.
Reset user permissions
When macOS 10.12 Sierra was released, a different problem appeared, in which permissions were apparently set incorrectly not in system files generally, but in the user’s Home folder, specifically in ~/Library/Preferences. To address this Apple added a new verb to the already complex command tool diskutil, resetUserPermissions, and described how to use this in a support note. It’s perhaps no coincidence that this new problem appeared at about the same time that the cfprefsd service took on management of those preference files, and just one year after repairing disk permissions ceased.
At that time, the following problems were attributed by Apple to incorrect permissions in ~/Library/Preferences:
changes to preference settings, particularly those for System Preferences, do not ‘stick’;
changes made to the Dock do not ‘stick’;
you are asked to authenticate when trying to move or alter some folders in your Home folder;
when trying to save, you are told that the file is locked, or that you don’t have permission;
Preview, TextEdit, and App Store apps (which are sandboxed) may crash when opened;
alerts appear warning that the startup disk has no more space available for app memory;
Safari or SafariDAVClient use large amounts of resources (memory);
the Mac runs very slowly;
iTunes cannot sync a device;
there are problems with Photos or iPhoto libraries, including inability to import into the library, or forgetting the library each time the app is opened.
Most if not all of those could have been attributable to problems resulting from bugs in cfprefsd.
Repair Home permissions
Five years ago, Apple changed its recommendations to include running a new tool repairHomePermissions in Recovery mode, then re-installing macOS. Shortly afterwards, when Big Sur was in beta in June 2020, Apple withdrew that support note and all reference to repairing permissions, although the tool is still available in Recovery mode even on Apple silicon Macs.
Running repairHomePermissions from Terminal in Recovery launches a GUI app to repair permissions on a selected Home folder on the Data volume. However, I strongly recommend that you don’t try using this, as you’ll end up with the user being locked out of every folder in their Home folder. I have tried it three times in virtual machines, and each time I have had to discard that VM because of the problems it caused.
Delete a corrupt preference file
Regardless of those, there are still occasions when preference files can cause problems. These typically occur when a corrupt or damaged preference file causes an app or other code to crash, usually when it’s being launched. Although these are now far less common, and the SSV ensures that system files can’t become corrupted as they did in the days before SIP, it’s useful to know how to deal with them.
On most occasions, a preference file can be deleted in the normal way, either in Finder or Terminal, and it won’t return until that app is run again, as it won’t currently be managed by cfprefsd. The alternative is to use defaults: defaults delete com.mycompany.appname
deletes all the key-value pairs within the preference file for com.mycompany.appname, leaving just the empty property list. This has the advantage that it can be used when cfprefsd is managing that file’s contents, so should always be reliable. Provided the app handles preferences correctly using UserDefaults, it should be able to repopulate the empty property list the next time that app is launched.
One significant caution is when working with files inside ~/Library/Containers,~/Library/Group Containers,~/Library/Daemon Containers and similar managed folders. Because these form sandboxes, macOS manages them differently and tampering with their contents is likely to have unintended effects, so is best avoided, although the defaults command should still be safe.
Summary
Repairing disk permissions on system files ceased with SIP in El Capitan.
Repairing permissions on Home folder preference files is no longer recommended by Apple, since Big Sur.
Safe and robust deletion of contents of a preference file can be performed using defaults delete.
Don’t tamper with files inside ~/Library/Containers, ~/Library/Group Containers and similar folders.
Never be tempted to run repairHomePermissions in Recovery mode.
All of us at some time or other find our mind has gone blank and we can’t remember the password we’ve typed in so often before. Or the person who did know that password may no longer be there to recall it for us. At times like these we may need to gain access to a locked Mac. This article looks at how you can do that in an Intel Mac with a T2 chip, or an Apple silicon Mac, running Big Sur or later, in particular macOS Tahoe. If you want information for an older Mac or macOS, this article should be more helpful.
Keyboard
If you’re certain you entered the correct password but it was refused, check the Caps Lock key isn’t on, and check the Mac is using the correct language keyboard in the menu at the top right.
Firmware password (Intel only)
Intel Macs can be protected using a firmware password set and removed in Recovery, and that can normally only be removed if you know the password. If you don’t, the most reliable way to achieve this is to take the Mac to an Apple store, together with proof of purchase or ownership, and ask them to remove the firmware password.
Trying to guess a Mac’s password is doomed to failure: you only have ten attempts before you have to try in Recovery, and an absolute maximum of fifty attempts in total before access to its Data volume is permanently barred, and that Mac has to be restored in DFU mode. Time intervals are also added between attempts, starting at a minute after the third attempt, and rising to eight hours with the ninth.
Once you realise you don’t know the password, click on the ? to the right of the password entry box. If you keep trying to guess, your attempts will soon be delayed by lock periods that grow up to eight hours.
The Mac will then offer you the best option for resetting the password. If the Mac was opted into iCloud Recovery, you’ll then be asked for details of the Apple Account.
This is now handled by the Recovery Assistant, which also helps you use the Recovery Key if iCloud Recovery wasn’t chosen.
If you don’t have Apple Account details or the Recovery Key, the remaining option is to wipe the Mac. That’s offered in the Erase Mac command in Recovery Assistant’s menu.
For these the Mac needs an internet connection. Further details are in this support article. If you’ve forgotten your Apple Account password, Apple’s support article here should help.
Missing owner
Those methods all assume that you’re the owner/user, have simply forgotten your login password, and can recall your Apple Account details or Recovery Key. If the Mac belonged to someone who’s no longer there, and you don’t have access to their Apple Account, you won’t be able to use those options.
There are two further steps now available that you may find helpful. Provided your Apple Account has two-factor authentication enabled, if you’re unable to sign in or reset your password, you can ask Apple to perform account recovery. This isn’t immediate, but provided you can satisfy Apple that your request is genuine, it should prove possible.
As of macOS 12.1 and iOS/iPadOS 15.2, Apple has supported Legacy Contacts, but those must be set up before you need to use them. The Legacy Contact is then provided with an access key they can use in the event that you can’t because you’re dead. Apple also needs to see a copy of the death certificate before giving full access to the account for a period of three years. Full details are here.
Still no solution
If you want to access the Mac but not its contents, it’s straightforward to return Apple silicon and T2 models to factory condition by putting them into DFU mode and restoring them, as explained here. That may not always be a good step, though: when you try to set that Mac up again, it checks in with Apple. If it has been registered as stolen, you could find it becomes unusable.
If all else fails, get expert advice and help from Apple stores, authorised service providers, and from the many independent Mac technicians around the world who are often only too familiar with these problems.
Virtual machines
Depending on how they’re set up, macOS VMs can now support either iCloud Recovery, or a Recovery Key, provided the guest macOS can.
Sometimes apps that should run fine seem to find problems where there shouldn’t be any, becoming slow to launch, unable to update, erratic, and easily crashed. One reason that can account for these is that the app has become stuck in translocation. This article explains how you can check that, and what you can do to solve it and restore the app’s normal function.
App translocation, or Gatekeeper Path Randomisation (GPR), is a security mechanism intended to disrupt malicious code that’s dependent on its immediate location, perhaps to access other code in plugins. When a new quarantined app is run from the same folder it came in, it’s copied to a random path that appears as a volume, typically hidden at something like /private/var/folders/x4/[random chars]/T/AppTranslocation/[UUID]/d/, and run from there. However, it’s only present there while it’s running, and the moment you quit the app that location is unmounted, and vanishes.
In theory, translocation shouldn’t affect an app, but when it occurs repeatedly, it’s likely to prevent it from updating itself, and have other adverse effects. When an app has been translocated once, unless something is done to prevent further translocation, it’s likely to suffer the same fate every time it’s run, so becoming stuck in translocation.
Testing
To determine whether an app is being run from translocation, you need to discover the path of its executable when it’s running. That’s simple to do using Activity Monitor:
Run the app from the Finder as normal.
In Activity Monitor’s CPU view, locate the app in the list of processes, and select it there.
Click on the ⓘ tool above to inspect the process.
Look at the Executable Path given there.
If the path starts with anything like /private/var/folders/x4/[random chars]/T/AppTranslocation/[UUID]/d/, then the app is being run in translocation.
If you’d prefer to perform this in Terminal instead, run the app, then enter the command ps xw | grep AppName
to see its executable path. This was suggested by Quinn “The Eskimo!” of Apple’s Developer Technical Support.
Fixing
App translocation occurs when all the following apply:
the app has a com.apple.quarantine extended attribute attached;
the app must be opened by Launch Services (normally the Finder) rather than a command shell;
the app hasn’t been individually moved in the Finder from the folder it was unarchived or downloaded to, wherever that was.
One common error that falls foul of those rules is when two or more apps are moved together from the Downloads folder into Applications, and another is to move an app inside the same folder it came in, into Applications.
Although you can strip the com.apple.quarantine extended attribute from the app, it’s simpler and better practice to:
Move the app (one at a time) to another folder in the same volume, then run it from that location.
Move the app back to the folder you want to keep it in, preferably in one of the standard Applications folders.
Run it again from there and confirm that it’s no longer translocated.
Future updates should then work fine, and the app should be spared any further translocation.
Summary
If an app isn’t working or updating properly, suspect it might be stuck in translocation.
Run the app and inspect its Executable Path in Activity Monitor to determine whether it’s being translocated.
If it is, move it elsewhere, run it, move it back, and check again.
If you ever encounter an error when checking an APFS volume using First Aid in Disk Utility or fsck_apfs, you won’t be informed of the path and name of the item responsible, but given its inode number, in an entry like warning: inode (id 402194151): Resource Fork xattr is missing for compressed file
The inode number given can only be resolved to a path and file/folder name if you also have a second number giving the volume for that item. As that will be for the volume being checked at the time, you should be able to identify that immediately. The only time that you might struggle to do that is with items in a snapshot; those should, I think, be the same as the volume they are taken from. However, as snapshots are read-only, there’s probably little point in pursuing errors in them.
To resolve these in my free utility Mints, open its inode Resolver using the Window / Data… / Inode menu command. Drag and drop another file from the same volume onto that window.
The Resolver will then display that file’s volfs path, such as /.vol/16777242/1241014
All you need do now is paste the inode number given in the warning or error message in Disk Utility or fsck_apfs, into the Inode Number box at the top of the Resolver window, and click the Resolve button. Mints then looks up information for that inode number on the same volume, using GetFileInfo, and displays it below.
One drag and drop, a paste, and a click to discover what APFS is complaining about.
Command line
You’ll sometimes see Terminal’s find command with the option -inum recommended as a way to convert from an inode number to a regular path. Although you can do that, it’s easier to use the command GetFileInfo instead. For that you’ll need the full volfs path, including the volume number.
To find the volume number, use my free utility Precize, and open another file on the same volume. The second line in its window gives the full volfs path for that file. Copy the start of that, leaving the second number, the inode, such as /.vol/16777238/
Alternatively, you can use the stat command as given below.
In Terminal, type GetFileInfo
with a space at the end, and paste the text you copied from Precize. Then copy and paste the inode number given in the First Aid warning, to assemble the whole command, such as GetFileInfo /.vol/16777238/402194151
Press Return, and after a few seconds, you should see something like file: "/Users/hoakley/Library/Mobile Documents/com~apple~CloudDocs/backup1/0MintsSpotlightTest4syzFiles/SpotTestA.rtf"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 05/17/2023 08:45:00
modified: 05/17/2023 08:45:00
giving the full path and filename that you want.
GetFileInfo is one of the oldest commands in macOS, and has been deprecated as long as anyone can remember. I suspect that Apple is still trying to work out what can substitute for it.
Get a volfs path for a file
Use Precize to run this the other way around: open the file and read the path in that second line. To copy the whole of it, press Command-2.
The simplest ways of obtaining inode numbers and so building volfs paths in Terminal are using the -i option to the ls command, and for individual items using stat: ls -i lists each item in the current directory, giving its inode number first, e.g. 22084095 00swift
13679656 Microsoft User Data
22075835 Wolfram Mathematica
and so on; stat myfile.text returns 16777220 36849933 -rw-r--r-- 1 hoakley staff […] myfile.text
where the first number is the volume number, and the second is the inode number of that item, or /.vol/16777220/36849933.
You’ve just run First Aid in Disk Utility, or fsck_apfs, and that reports warnings or errors. What should you do next?
Failure to unmount
By far the most frequent error encountered in Disk Utility’s checks results from its inability to unmount a volume before it can start testing. While this is reported as an error, and it prevents the checks from running, it can sometimes be solved by manually unmounting the volume in question. It normally doesn’t indicate anything sinister, and is simply frustrating.
Repeat in Recovery mode
If the warnings or errors were reported on your current boot Data volume and you ran that check in normal user mode, consider starting your Mac up in Recovery mode to repeat the check there.
Although macOS does an impressive job of performing checks on a live volume, it’s more reliable and more likely to be able to perform any repairs needed in Recovery mode, when the Data volume isn’t mounted and live. When there, if you prefer, you can still use fsck_apfs in Terminal.
The other case where checks may be best made in Recovery are those on an active Time Machine backup volume. That’s because those can be difficult to unmount before running the checks, although that is possible as long as a backup isn’t being made at the time, or Spotlight indexing taking place. The sure way to avoid those is to do so in Recovery mode.
Warnings or errors?
Any remarks about problems or irregularities encountered during checks should make explicit whether they are warnings or errors, and it’s essential to make a clear distinction between them.
Warnings are observations that could have significance, or might be perfectly normal in the circumstances. Only an APFS engineer is likely to be able to tell the difference. Among the commonest are those reporting missing xattrs for compressed files: warning: inode (id 113812826): Resource Fork xattr is missing for compressed file
Experience is that those aren’t related to any consequent errors, and you should be able to leave those alone.
Errors are abnormalities that do have more significance, and might have the potential to cause further problems. Where possible, First Aid or fsck_apfs should attempt to repair those, most probably by performing “deferred repairs”. Those are normally minor errors that it already has plans to attend to when that volume is next mounted, the time that APFS normally performs its routine maintenance.
Snapshots
These are read-only copies of the file system metadata at a previous instant in time, and are associated with retained storage blocks. They aren’t part of the active volume, and their metadata are separate. As they’re read-only, any warnings or errors are most unlikely to be fixed, so you have a choice of leaving that snapshot to be deleted routinely by age, or deleting it early yourself.
Snapshots are made by backup utilities including Time Machine, which are required by Apple to have a mechanism that will delete them automatically after a set period. In the case of Time Machine, that’s when the snapshot is over 24 hours old. Snapshots aren’t backups, but augment regular backups, and stand in for them when backup storage isn’t available. In general, there seems little point in deleting a snapshot early just because there’s a reported warning or error for it, as that won’t affect the health of the active volume.
Identifying faulty items
Warnings and errors related to specific files or directories are normally given with an item id, which should be their inode number. To go any further, you’ll need to convert that to a path and file/directory name. You should therefore copy and paste all reports into a separate file as reference. Resolving an inode to a path and item name is detailed in this article.
In many cases involving items that can be resolved to an existing path, the faulty item is in one of the hidden folders such as .Spotlight-V100 for Spotlight indexes, or .DocumentRevisions-V100 for the document version database. In the former, rebuilding Spotlight’s indexes may resolve the problem, but you’re unlikely to be able to do anything about the latter.
If the inode resolves to a regular file, deleting that can remove the problem, but when you try restoring that file from a backup you may discover the backup has the same problem. Getting to the bottom of a recurrent file system error might require the knowledge and skills of an Apple engineer. Consider reporting this using Feedback, as it should then help iron out any remaining bugs in APFS.
You should also consider whether your Mac might be running old third-party software that is causing recurrent errors. Normally, products should work at a higher level that isolates them from the file system itself, but there are some surprising exceptions. If you can identify a cause, please inform the developers of that software so that it can be fixed.
Old versions of APFS
One potentially dangerous practice occurs when an older version of APFS changes a newer file system. APFS back in High Sierra and Mojave knew nothing of boot volume groups, firmlinks, or many of the features of more modern versions of APFS. If you really must run different versions of macOS on the same Mac, or shared external storage, avoid such version conflicts, and never run an older version of Disk Utility or fsck_apfs on a newer APFS container or volume.
Following the introduction of the Unified Log, a surprising number of folk you would expect to use it have stopped. Some experienced developers and those providing advice in Apple Support Communities seemingly take pride in their lack of log literacy, claiming that the log is now impossible to use, and only accessible to Apple’s engineers. While it does present obstacles, pretending that the log isn’t a vital tool in diagnosis and understanding is burying your head in the sand. This article shows why.
Why the log?
The log provides support for several purposes. It’s widely used to investigate events such as bugs and unexpected behaviours, to establish their cause before working out how to fix them, in diagnosis and troubleshooting. It’s also used to discover how subsystems within macOS work, and what they do. Examples of those include LaunchServices, DAS-CTS scheduling and dispatching, and RunningBoard, all of which are nearly invisible to other methods, but write copious and explicit entries in the log. With its precise time recording and special Signpost log entries, it’s also invaluable for measuring performance, hence in optimising code.
Concentrating on the log’s use in diagnosis, log entries can be used to answer most of the key questions:
What happened?
When did it happen?
Who made it happen?
How did it happen?
Why did it happen?
What can I do about it?
Diagnose a mystery update
To illustrate those in practice, I’ll use an example that happens to be fresh in my mind, the silent updating of XProtect data last week. The only two clues available outside the log were the fact that XProtect had been updated, and that had occurred at 06:46:43 GMT on the morning of 17 September. There was no record of this event anywhere else that might have given any better information on how it had occurred.
Browsing the log from one second earlier confirmed what and when that had happened. I quickly discovered who made it happen when I found the log entry 2025-09-17 06:46:42.615072 com.apple.duetactivityscheduler REQUESTING START: 0:com.apple.security.syspolicy.xprotect-update:7874AD
revealing that update had been accomplished by a background check scheduled and dispatched by DAS-CTS, and performed by an update service com.apple.security.syspolicy.xprotect-update.
That in turn fired up XProtectUpdateService, which recorded that it promptly completed and activated the update: 2025-09-17 06:46:42.695517 com.apple.xprotect Connecting to XProtectUpdateService
2025-09-17 06:46:42.744182 com.apple.security.XProtectFramework.XProtectUpdateService XProtectUpdateService booting
2025-09-17 06:46:43.157255 com.apple.security.XProtectFramework.XProtectUpdateService Attempting to apply update: [private]
2025-09-17 06:46:43.191178 com.apple.security.XProtectFramework.XProtectUpdateService Update completed. Activated update [private]
XProtectUpdateService initiated a connection to the iCloud service now used to update XProtect in Sequoia and later, but log entries didn’t show the update being downloaded from that source. Instead, there was an error reported in the entry 2025-09-17 06:46:43.193159 com.apple.syspolicy.activities Finished Xprotect update in 496.4100122451782 ms: Error Domain=XProtectUpdateError Code=2 "Activated update LocalUpdate[5315]" UserInfo={NSLocalizedDescription=Activated update LocalUpdate[5315]}
Although the messages in many of these log entries are opaque, that entry makes it clear that XProtectUpdateService hadn’t downloaded the new version from iCloud, but had activated a local update, which we know from experience means the copy already downloaded to the traditional XProtect location had been used to install that update in its new location. That used to be available to the user through the xprotect update command, but is no longer. Thus, the only way that update could have been installed was the result of com.apple.security.syspolicy.xprotect-update being run routinely.
If we can’t intervene and force the update manually, the final piece of information we need is how often com.apple.security.syspolicy.xprotect-update is run, and that’s revealed into a later log entry: 2025-09-17 06:46:43.202474 com.apple.duetactivityscheduler Submitted: 0:com.apple.security.syspolicy.xprotect-update:58B6CE at priority 5 with interval 86400 (Wed Sep 17 22:58:51 2025 - Thu Sep 18 18:58:51 2025)
i.e. every 86,400 seconds, or 24 hours.
Procedure
How difficult was that to discover? Even with minimal prior knowledge, consummately easy, and it only took a couple of minutes.
My starting point was the timestamp reported for the update by xprotect version, of 06:46:43 GMT. I therefore set LogUI to display 5 seconds of log starting from one second before that. In the screenshots below, times are shown in BST, one hour in advance of GMT.
This returned a total of 7,174 log entries, far too many to browse. Knowing that I was looking for entries concerning XProtect, I then typed that into the search box and pressed Return, to display only those entries whose message contained the text xprotect.
That narrowed down the number of entries to just 65, starting with the scoring and dispatch of com.apple.security.syspolicy.xprotect-update by DAS-CTS at 42.608967 seconds, and containing all the entries quoted above. Just to be certain that I hadn’t missed anything relevant, I then cleared the search box and pressed Return to display all log entries again, scrolled down to 42.608967 seconds, and checked through those for the period to 43.19315 seconds, when the update had completed.
Of course, not all log investigations are as simple or successful, but many are just as straightforward. The main limitation isn’t the excessive number of log entries, but those from subsystems that make very few entries, as occurs in Spotlight indexing and search. There’s always a way to filter out unwanted entries, but you can’t magic in entries that were never made in the first place.
Conclusions
Browsing the log might appear daunting, even overwhelming or terrifying at first, but as you become more familiar with it you appreciate the rich information it can provide. Log literacy is one of the basic skills required for anyone who wants or needs to dig deeper into their Mac or Apple device. Without it diagnosis, research and performance measurement are like trying to paint a landscape while wearing a blindfold.
Login
