Q: External hdd won't eject properly since El Capitan

Oddly, seems to be working again this morning. Feeling hopeful again... Cheers!

I am mystified that someone can respond with "Problem went away after I rebooted" and have that qualify as an excepted answer. Of course, the problem went away after a reboot. It is a problem with a running process (in this case it's Spotlight). What's interesting is that Spotlight doesn't seem to honor it's Privacy Settings, which should be a source of concern for folks and something that Apple should be admonished for. Here are a couple of pointers to working around the problem (a solution is entirely in Apple's court):

Scenario 1 - you want to have the drive indexed, but you also want to eject the drive temporarily:

Stop the indexing process, eject the drive, and restart the indexing process (this is the bug that Apple needs to fix):

a. sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

b. Eject the drive from Finder, or from the command line with diskutil eject whateverDisk

c. sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

Scenario 2 - you don't want the drive indexed, ever, and you want to eject it.

Stop the indexing process, add the external drive to the Privacy Tab of Spotlight's Settings, under System Settings, add a metadata file to the volume, remove the spotlight files, eject the drive, restart the indexing process:

a. sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

b. sudo touch /Volumes/Whatever/.metadata_never_index

c. sudo rm -fr /Volumes/Whatever/.Spotlight-V100

d. eject the drive from Finder, or from the command line with diskutil eject whateverDisk

e. sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

I hope this helps someone a bit better than "reboot"

1) Bravo for this post decuser - spot on to the root of the problem as far as I can see, a solution, and saying why a reboot 'workaround' is anything but.

2) What I've observed: whatever has been redone with mds/mdworker/Spotlight seems to be at the core of a raft of issues beyond disk ejection.  Apparently the indexing is what produces the App/Photo/Music "bands of color" in the new diskutil UX - which may or may not have anything to do with why "verify/repair disk" may be gone in the DiskUtil App, but has something to do with a separate problem where El Capitan relies on spotlight data for filesystem info - and seemed to confuse the difference between what gpt / DiskUtil cli disk info is produced, and what El Capitan actually sees / reports coming from spotlight (example: incorrect disk size info and bizarre problems with partition tables.)

It appears that not only is Spotlight engineered to look at everything (which it ~generally should as an indexer for user info, with limits like not saturating a bunch of network shares at an office), but also used to determine acceptable kernel-level actions like ejecting disks or reporting filesystem info (which it should not, unless it's bulletproof - and it's clearly not bulletproof yet.)

Only adding the info above because while I'm disappointed that this issue is still not fixed, I think it's related to a whole bunch of complexity that got added to El Capitan - even before you add SIP over the top - and might help others look into this.

TLDR; For Apple product manager: I can live without knowing what % of my disk is taken up by photos as long as my storage works as expected.

I do have a fix guys, at least in my case. I use El Capitan almost without issues till the begin of March'16 and then I came across issue with not working Eject button located next to external drive in Finder. It affected any external or mounted drive like usb stick or dmg mounted to install any app. Of course I could use terminal command "diskutil eject" and this did the job but this was not a solution for me so I've installed a free app called Onyx which is a tweaking tool for Mac OS and I pressed 'default' button in tabs which have any common things to Finder. All is now fixed even without restart I just hope it will last this way long time.

If Eject doesn't work in a given window, sometimes it will work if you open a new Finder window and then try ejecting.

I have downloaded the latest El Capitan update today but I am sorry to say that this "Disk Eject" problem is still with us. I was hoping for a fix but it now seems to me that Apple are not bothering with it. Somewhat sad as it is annoying even if it does not give me much of a problem.

I am pretty sure someone else spoke of it but adding the disk to spotlight privacy didn't work for me. What worked for me was downloading the free (donation) app called "What's Keeping Me". It shows you what app is preventing ejection and allows you to kill it from the interface. Easy peasy.  A lifesaver for me.

NM

Agreed.  Restarting a computer will TEMPORARILY solve a lot of little issues.  But what's the solution to getting this fixed permanently?  I have 6 external drives connected to my 27" iMac running 10.11.3, and 90% of the time cannot eject them.  I'm concerned that force ejecting them will corrupt the file system over time.  I have a dozen applications running when I work, and can't afford to simply "reboot" anytime OSX decides to have a hiccup.  Is Apple looking into this at all?

iMac Retina 5K, 28-inch, Late 2015

4Ghz Intel Core i7

32GB 1867Mhz DDR3

512GB SSD

Various external drives:  USB 3 and USB 2, some are external SSDs, others conventional.

I had a drive become corrupted while I was trying to figure out how to keep it from being indexed. I was forced to power off and power back on because OS X wouldn't reboot. I repartitioned that drive and restored it from time machine and then set it up not to be indexed and all has been well with that drive since. I echo your query - when will apple address the problem permanently? It seems to be pretty low on their list.

This sounds good, but if they fixed it, why don't they list the fix with the update note? Anyway, thanks for the update.

I'm running 10.11.4 and the issue is unresolved. I've experienced the problem as recently as today, in fact. EVISCERATOR might be a little over eager. I believe the issue still exists (and also believe it would have been noted in the update).

Thanks for elaborating, Tom. The added insight is appreciated. Please keep us posted should the issue remain at bay, or pops up again. Cheers!