When a volume won’t eject, sometimes force-quitting the Finder will let you eject it after the Finder relaunches. On the keyboard, enter Command-Option-Escape, and from the Force quit window that will appear, select the Finder. After the Finder relaunches, quickly eject the trouble volume before the problem reoccurs.
A utility named “What’s Keeping Me” will give you info on which files are open on a volume, and which apps have them open, which can prevent a volume from being ejected, but it may be more technical than most people want to deal with.
However, force-quitting the Finder or closing files and apps may not be a permanent solution for a volume that won’t eject. In most cases, when a volume still won't eject, Spotlight is the culprit. Normally, if Spotlight isn’t having any problems indexing a volume, you can eject that volume before Spotlight is finished indexing it. But sometimes Spotlight has difficulty indexing some files that contain data that Spotlight doesn’t understand, and when this happens, one or more of the specific processes that Spotlight uses (mds_stores, mdworker, mdimporter) will keep those problem files in some pseudo-open state that prevents the volume that they’re on from being ejected--Spotlight isn’t actually keeping these files open, but it continues to “track” them, preventing volume eject, so a more accurate description of this problem may be that Spotlight is keeping open its own index files on the trouble volume, or in some other state that prevents the volume that they’re on from being ejected (these index files are contained in the volume’s invisible folder named “.Spotlight-V100”). The ‘md’ processes aren’t hanging completely, since Spotlight can proceed with indexing the rest of the volume. This problem has existed intermittently in OS X ever since Spotlight was introduced—sometimes Apple seems to have fixed it, and then it breaks again with an updated version of OS X. Many people have been reporting that OS X El Capitan has brought back this problem in force.
As described in this thread, to see what processes are busy looking at a volume, and what files they’ve got open, enter this into Terminal:
sudo lsof "/Volumes/[volume name]” (the quotes allow you to enter a volume name that contains spaces, but if the trouble volume’s name doesn’t have spaces, you don’t need to enter the quotes)
The command “lsof” stands for “list open files”. Whether or not Spotlight seems to be actively busy indexing the volume, and whether or not Spotlight has trouble ejecting the volume, the list will show several instances of the process “mds_store” are keeping open the Spotlight index files contained on the volume. If a volume has been added to Spotlight’s “Privacy” tab in Spotlight’s System Preferences pane, and hence isn’t indexing that volume, the lsof command will still show one instance of the mds process is looking at that volume, but it won’t show instances of mds_store is keeping any of the Spotlight index files open on that volume.
However, all this does is confirm that Spotlight is looking at a volume, whether or not Spotlight has trouble ejecting the volume--it doesn’t tell us what the problem is. On rare occasion, the problem is a damaged volume directory, which Disk Utility or another utility may be able to repair, but far more often, as I mentioned, Spotlight is having trouble indexing the contents of specific files whose data Spotlight doesn’t understand. To confirm that this is happening, open the Console utility, at Applications/Utilities, and use it to view system.log. There, one of the clues that Spotlight is causing the problem, will be lines something like this, which pinpoint the “dissenter” that’s preventing eject, as the process ‘mds_stores’:
Mar 9 01:45:55 Admins-MBP storagekitd[1143]: Unmount of disk1s2 blocked by dissenter PID=201 (/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds_stores) status=0x0000c010 (Resource busy)
Ideally, you’ll also see error references in system.log to other ‘md’-related processes like mdworker, and the OS X utilities that run them, like mdimporter, where they specify the pathnames of the files that they’re having trouble indexing. In the example below, the culprit is a file named “facebook.gif”:
Mar 9 01:31:02 Admins-MBP sandboxd[127] ([873]): mdworker(873) deny file-read-data /Volumes/250 gig/Users/johnsawyer/Documents/facebook.gif (import fstype:hfs fsflag:4809018 flags:240000005E diag:0 isXCode:0 uti
ublic.html plugin:/Library/Spotlight/RichText.mdimporter - find suspect file using: sudo mdutil -t 604696)
As you can see by the text at the end of this error message, sometimes the error even tells you the Terminal command to find the offending file, but this just returns the same pathname as is contained in the error message.
What to do? As suggested in this thread, first add the trouble volume to Spotlight’s “Privacy” tab in Spotlight’s System Preferences pane. Sometimes this works immediately, and sometimes it takes a while to take effect before you can eject the trouble volume, since Spotlight may need some time to release its hold on the files it couldn’t index. You may have to force-eject the volume if this doesn’t work, but upon remounting the volume, usually it can then be ejected normally, since Spotlight will no longer be indexing the volume. Adding a volume to the Spotlight prefpane’s “Privacy” tab will also delete all of Spotlight’s hidden index files from that volume, so if the no-eject problem was caused by Spotlight having a corrupted index file, you can make Spotlight rebuild these index files by removing the volume from the Spotlight prefpane’s “Privacy” tab. However, if the real problem was due to files that Spotlight doesn’t understand, that won’t fix the no-eject problem.
If you don’t want to turn off Spotlight indexing for the entire volume, then if the trouble files are contained in folders you don’t need to have Spotlight index, you can add those specific folders to the Spotlight prefpane’s “Privacy” tab (the Privacy tab will accept only folders, not files).
However, adding volumes or folders to Spotlight’s “Privacy” tab will “fix” the problem with the non-ejecting volume only when it’s mounted under the same startup volume that was running the Mac at the time you put the trouble volume or its folders into Spotlight’s “Privacy” tab, since that privacy setting is stored only that particular startup volume--not on the trouble volume. So, if you mount the trouble volume under another startup volume, the problem is likely to return. If you want to prevent the trouble volume from being indexed by Spotlight no matter what startup volume it’s mounted under, create a plaintext file in TextEdit with no content, and save it to the top level of the trouble volume with the title of .metadata_never_index. In TextEdit, uncheck the option to use extension "txt”, or just delete the .txt suffix from the filename field in the Save dialog, and when TextEdit alerts you that filenames beginning with a dot will be invisible, click ‘Use “.”’. If you’re using TextEdit on a newer version of OS X, it may not have the option to not append an extension to the filename, even if you delete the .txt suffix from the filename field in the Save dialog, in which case it will automatically add the suffix ‘.rtf’. If this happens, after you save the file, you’ll need to use a utility that makes invisible files visible, and remove the .rtf extension manually.
Another way to put an end to the trouble volume’s specific cause for its eject problem, is to track down all the files on that volume that Spotlight is having trouble with (see below), and trash them (if you want to save them, back them up onto another volume you don’t normally use, or burn them to an optical disc), or archive them into a compressed file on the volume, which Spotlight won’t try to index.
There may be a Terminal command to list all the files (and their paths) that Spotlight is having trouble with, but I don’t know Terminal well enough to provide that (though the answer to that might be found somewhere else, like at
http://www.thexlab.com/faqs/stopspotlightindex.html), but here’s another method:
To have Console display a list of the files that Spotlight is having trouble with, use Console’s ‘Search’ field to search system.log for this string, right after you find that you can’t eject the volume:
deny file-read-data [this will also return all instances of the string ‘deny(1) file-read-data’]
Unfortunately, looking through this list can be difficult, since it will also contain a lot of other text in addition to the pathnames of the trouble files. If the number of trouble files isn’t too large, you can backup/trash/compress them without too much trouble. But if it’s impractical to backup/trash/compress the trouble files (either because the list is too long, or because you need to keep these files on the volume and in an uncompressed state), or if you find that the problem remains even after trashing the trouble files (some other Spotlight bug might be at fault), then you can force-quit from Spotlight’s mds process, by entering this into Terminal:
sudo killall mds
...then unmount the volume quickly, before mds relaunches. If you added the volume to Spotlight’s “Privacy” tab in Spotlight’s System Preferences pane, then the next time you mount the volume under the same startup drive, it’s more likely (but not certain) to be unmountable. Sometimes Spotlight’s System Preferences pane ignores the contents of its Privacy tab. I don’t know the fixes for that. Also, there may be other issues with the volume, besides Spotlight, that prevent ejection, but I don’t have the fixes for those issues handy at the moment.
