Every day I make a backup of my macOS home folder with a command like the following:
hdiutil create -encryption -format UDZO -noatomic -noscrub -srcfolder /Users/jeff -verbose /Users/Shared/backups/2025-2-13.dmg
Yesterday my backup failed, because it couldn't copy a file inside the ~/Library/ directory. The onDeviceCompilationCaches directory and its contents were created the previous day at 5:16PM; it did not exist in the previous day's backup (created at 4:47PM). At first I thought the hdiutil failure was the same old bug introduced in macOS Sonoma that I blogged about before: Can't create disk image containing locked file. However, I didn't find any locked files this time. I did find two bizarre files that I can neither read nor copy (using cat and cp, for example), not even with sudo, not even with System Integrity Protection (SIP) disabled. Both files are exactly 6799360 bytes in size. One file is in the secondPassChecker subdirectory:
24D70-adee8808d041f179fca66b3a4bfa95346d6df819_15.1033.1-galvatron_hsjs_v1_8bit_fp16_mil2bnns-15.1033.1-en-US.bnnsir
And the other file is in the speakerRecognition subdirectory:
24D70-adee8808d041f179fca66b3a4bfa95346d6df819_15.1033.1-int8_conformer_matrix_split-15.1033.1-en-US.bnnsir
The 24D70 prefix in the filenames is actually the build number of macOS 15.3.1, which you can see in the About This Mac window under the menu. I used the ls -@FOPel% command to print as much information as possible about the files, but there was nothing out of the ordinary:
-rw------- 1 jeff staff - 6799360 Feb 12 17:16
They're regular files with no extended attributes, no file flags, no Access Control List, etc. There's no apparent reason why I shouldn't be able to read or copy the files.
I do think I know where the files came from. After the macOS 15.3.1 update re-enabled Apple Intelligence, I decided to change my Siri language, because I heard that this was a workaround to prevent Apple Intelligence from getting enabled.

This process was a bit involved, because I have a configuration profile that disallows Siri. So I had to edit my profile, reinstall it, enable Siri, change the Siri language, disable Siri, edit my profile again, and reinstall it again. The last modified time of my .mobileconfig file was 5:22PM Wednesday, which is around the same time that the .bnnsir files were created. Moreover, comparing Wednesday's backup of ~/Library/ to the current directory, I found several new subdirectories group.com.apple.siri.inference, group.com.apple.siri.referenceResolution, and group.com.apple.siri.remembers that were all created at 5:17PM Wednesday, within one minute of the .bnnsir files. The circumstantial evidence seems strong.
Thus, the mystery to me is not where the files came from but rather why I can't access them.
Searching the web, I found a small number of references to the same problem. There's a post in the macOS Sequoia Apple Support Community from December 22, 2024:
Steps I took:
- Created a APFS volume on an external SSD
- Copied the home folder from the internal HD to the external HD
- During the process it stops and I get the following message:
The operation can’t be completed because you don’t have permission to access “24C101-915b2b7b58cda908d393076c1774553c56bf6550_15.1033.1-int8_conformer_matrix_split-15.1033.1-en-US.bnnsir”.This file appears to be located at the following pathway: /Users/MyHomeFolder/Library/Group Containers/group.com.apple.CoreSpeech/Caches/onDeviceCompilationCaches/speakerRecognition
There's a post in The Lightroom Queen forums (Adobe Lightroom, that is) from January 3, 2025:
Coincidentally I found an odd error crop up in my ChronoSync backup error logs of my main drive.
Error: Source Target encountered error: "File is exclusively open by another application."
/System/Volumes/ Data/ Users/ tom/ Library/ Group Containers/ group.com.apple.CoreSpeech/ Caches/ onDeviceCompilationCaches/ speakerRecognition/ 24C101-5be543f40a3ad19ea0c8f119fa9659f06a4c746b_15.1033.1-int8_conformer_matrix_split-15.1033.1-en-CA.bnnsir
Most informative (relatively speaking) is a Reddit post in r/synology from January 14, 2025:
Our developers identified a workaround that involves removing (or relocating) certain files generated by macOS speech recognition. We encourage contacting Apple directly and referencing bug FB16090831. However, if you wish to attempt a workaround, please note it involves deleting or moving speech recognition files from your Mac, which may affect speech recognition functionality. Proceed at your own discretion:
Identify the error in log files:
Search for lines referencing diskXsY Couldn't get/unwrap ekwk in crypto_id <inode_value>, err 1.
Find the affected file using find and the inode value:bashCopier le codesudo find / -inum <inode_value>
Check if the file has a .bnnsir extension.
If so, it is likely a macOS speech recognition cache file.
So there's an Apple Feedback Assistant bug report (FB16090831), though of course I can't access it.
I ended up just deleting the onDeviceCompilationCaches folder, and then my home folder backup completed successfully. But the file access mystery remains. What exactly caused those .bnnsir files to be inaccessible?