The weapon of choice in such a case is lsof:
sudo lsof | grep /Volumes/FOO
In my case, this produced a list of files opened by a process called mds_store
which, apparently, is used
to produce the Spotlight search index:
mds_store 42059 root txt REG 1,6 3277 8832664 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexGroups mds_store 42059 root txt REG 1,6 32768 8832663 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexIds mds_store 42059 root txt REG 1,6 8192 8832666 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexTermIds mds_store 42059 root txt REG 1,6 8192 8832668 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexPositionTable mds_store 42059 root txt REG 1,6 8224 8832669 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexDirectory mds_store 42059 root txt REG 1,6 1024 8832670 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexCompactDirectory mds_store 42059 root txt REG 1,6 65536 8832671 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexArrays mds_store 42059 root 5r DIR 1,6 2074 8832643 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842 mds_store 42059 root 11r DIR 1,6 2074 8832643 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842 mds_store 42059 root 47u REG 1,6 28 8832650 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/indexState mds_store 42059 root 49u REG 1,6 118784 8832674 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/.store.db backupd 42148 root 4w REG 1,6 1300 8832803 /Volumes/FOO/Backups.backupdb/Claus/2015-10-25-175619.inProgress/.Backup.467484979.422497.log
The fun part was that I had explicitly configured Spotlight to ignore that particular external disk - and yet, it was still trying to index it!
Turns out that I am not alone with this. "Disable Spotlight on a FAT32 external drive" provides the best summary I could find. Apparently, the type of file system on the external drive plays a role. I was somewhat skeptical about this claim, but then, all my external drives had FAT32 file systems on them, and so I followed the instructions in the article. I was still somewhat incredulous, as this seemed to be such a basic issue and the article is rather old.
But then, following the instructions indeed seemed to be successful, at least initially.
The magic ingredient in the sauce was to create a top-level file called .metadata_never_index
on
the affected drive:
touch /Volumes/FOO/.metadata_never_index
I was too impatient to wait for existing instances of mds_store
to finish their work,
and did not care about the consistency of the Spotlight index on the external drive anyway.
So I killed the mds_store
process right away, then unplugged the drive and plugged it in again.
From there, indeed I had no issues anymore with ejecting the external disk. Hmmm...
Other related articles and discussions: