The disk 'disk-name' wasn't ejected because one or more programs might be using it

Discussion in 'macOS' started by spam0000, Mar 15, 2011.

  1. spam0000 macrumors newbie

    Joined:
    Dec 7, 2009
    #1
    Hi,

    I often get this message when ejecting external harddrives:
    "The disk 'disk-name' wasn't ejected because one or more programs might be using it"

    I've been looking around for answers and found this command to snoop at what program might be holding it back:
    Code:
    spam0000$ sudo lsof -xf +d /Volumes/externaldrive/
    COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
    mds        41 root  132u   REG   14,8        0 999999999 /Volumes/externaldrive/.com.apple.timemachine.donotpresent
    mds        41 root  136r   DIR   14,8    32768         2 /Volumes/externaldrive
    mds        41 root  138u   REG   14,8        0 999999999 /Volumes/externaldrive/.com.apple.timemachine.donotpresent
    mds        41 root  140u   REG   14,8        0 999999999 /Volumes/externaldrive/.com.apple.timemachine.donotpresent
    mds        41 root  141u   REG   14,8        0 999999999 /Volumes/externaldrive/.com.apple.timemachine.donotpresent
    mdworker 1542 root    8r   DIR   14,8    32768         2 /Volumes/externaldrive
    mdworker 1542 root    9r   DIR   14,8    32768   5829386 /Volumes/externaldrive/Backup
    
    
    This would suggest that Timemachine is doing things to my disk. I have checked system preferences and Timemachine is off. How can I solve this?

    Cheers!
     
  2. -aggie-, Mar 15, 2011
    Last edited: Mar 15, 2011

    -aggie- macrumors P6

    -aggie-

    Joined:
    Jun 19, 2009
    Location:
    Where bunnies are welcome.
    #2
    Where are you getting Time machine has anything to do with it? It's Spotlight, which is indexing your drive. Turn off indexing for that drive.

    Go to System Preferences>Spotlight> Privacy. Go to “Prevent Spotlight from searching these locations:" Click the Add button, or drag a folder or disk into the list below that and your issue will go away.

    Edit: I love when people make posts for help and then you hear nothing back as to whether their problem is fixed.
     
  3. spam0000 thread starter macrumors newbie

    Joined:
    Dec 7, 2009
    #3
    Thanks for the quick anwer aggie!

    offcourse, the process using it is "mdworker", I was looking at the end of the line with "com.apple.timemachine"...

    seems like a bug?

    So, I got some questions to this:

    1. Disabling spotlight for the drive, that means that I wont be able to search it anymore? That is a major drawback to me.

    2. Is there a way, or even just a hack to make mdworker stop indexing files when I want to eject the drive?

    3. Is it risky to force eject the drive when this is happening?

    Cheers!
     
  4. John T macrumors 68020

    John T

    Joined:
    Mar 18, 2006
    Location:
    UK.
    #4
    Why not just let Spotlight finish indexing the drive? Depending what's on the drive, it can take some time.
     
  5. spam0000 thread starter macrumors newbie

    Joined:
    Dec 7, 2009
    #5

    I have had this issue with several external harddrives, also one which Ive had for a long time. It does not seem to stop. Unless by 'some time' you mean 2-3 years...
     
  6. spam0000 thread starter macrumors newbie

    Joined:
    Dec 7, 2009
    #6
    I found a temporary solution, which might also hint at what the real bug is. Force quitting (relaunch) Finder when the issue arises lets me eject the disk.

    I guess spotlight, and thus this 'mds' process, and Finder are linked somehow, and thats why force quitting Finder works.

    Anyhow, hope this gets fixed.
     
  7. AncientTech macrumors newbie

    Joined:
    Dec 31, 2011
    #7
    Check the Finder

    The Finder might be doing it. Viewing thumbnail images in the Finder (in Column View or Cover Flow View) can cause eject to fail with that error message. Solution: Cycle through your Finder windows and deselect *everything* (or just close the Finder windows, or switch to List View or Icon View). This might explain why spam0000 was able to eject after quitting the Finder.
     
  8. ancientartist macrumors newbie

    Joined:
    Oct 5, 2012
  9. Novaman macrumors newbie

    Joined:
    Jun 24, 2014
    #9
    Alternate solutions

    Just spent 4 hours on this problem. Since this remains the #1 Google link for a solution to the problem, I'll through in my two cents worth. It turned out to be Drive Genius' DrivePulse, but not really their problem per se. I had made a clone, re-initialized my boot drive, and when I pulled the application back via Apple's Migration assistant, it caused DrivePulse to run from the clone (which was the disk that wouldn't eject).

    Just a suggestion to others (which I learned through the process) look at the most logical major problems in turn before jumping into the uber solutions related to the first cause. In other words, see what you can do 1) in Spotlight to either let it run or turn it off via the System Prefs>Privacy setting; 2) check for items you can turn off one at a time in "Login Items" (Users); think about all the software you have running in the background right from startup - antivirus, drive monitors, malware monitors, etc. If those easy (non-destructive/non-Terminal) solutions don't work, progress to the more techie solutions according to your comfort level. And then if worse comes to worse you can always try the hard core - erase your drive and start over options. I always prefer to leave those to last.

    And I am assuming anyone trying to solve this problem knows not to intentionally launch programs when doing this trouble-shooting. Otherwise what you have launched could be the problem.

    Hope that helps someone else save time with this vexing little problem.
     
  10. kironin macrumors 6502a

    kironin

    Joined:
    May 4, 2004
    Location:
    Texas
    #10
    Believe it or not this is still a problem in El Capitan. It was NOT a problem ejecting my Carbon Copy Cloner backup USB3 backup disks under Yosemite. Now it gives this error and refuses to eject. The Spotlight fix does not work. I've never used the time capsule junk and that's completely off. Nothing is running. I have no google drive junk. It just very frustrating that Apple does nonsense like this. Finally just had to stop wasting time and force eject. Hope the back up is okay. Dammit Apple fix this.
     
  11. pws442 macrumors newbie

    pws442

    Joined:
    Feb 23, 2011
    #11
    I'm with you Kironin, Never had to do this before El Capitan! Dammit Jim, fix it.
     
  12. suereinberg, Dec 24, 2015
    Last edited by a moderator: Dec 24, 2015

    suereinberg macrumors newbie

    Joined:
    Oct 6, 2015
    Location:
    canada
    #12
    Hello and Merry Christmas! I am having this same problem. I have now went to the:

    Go to System Preferences>Spotlight> Privacy. Go to “Prevent Spotlight from searching these locations:" Click the Add button, or drag a folder or disk into the list below that and your issue will go away section but I'm not sure what folder or disk to drag over?

    I am having problems with my WD-Harddrive ejecting it keeps on coming up with an error that says "The disk "WD-Harddrive wasn't ejected because one or more programs may be using it"

    thanks you
    sue
     
  13. iUseMacBooks, Dec 26, 2015
    Last edited: Dec 26, 2015

    iUseMacBooks macrumors member

    Joined:
    Jun 2, 2015
    #13
    Hey all, Merry Christmas and Happy Holidays

    I just wanted to add that I am also having this problem. I recently got a 1 TB Western Digital "My Passport" HDD, and did a full backup with Time Machine. Once Time Machine finished it's full backup of the OS and my files, I got the notification that it was completed. I clicked the "Eject (my) Backup" disk, but it says one or more programs may be using it. I guess I could force elect it, but I'm pretty hesitant to do so. I don't want to ruin or damage any of the files that I just spent hours backing up. As of right now I still haven't ejected the HDD, do you guys think it'd be safe to force eject? Maybe I'll give it another hour or so and see if the unknown program that is still using the disk finishes up ... I've gotten into the habit of running to this forum whenever I encounter a problem lol hope everyone on here is enjoying the holiday season.

    EDIT: Just wanted to update my post to say that I restarted my MacBook Air and the problem was fixed cleanly, no data was lost.
     
  14. tokyojimu macrumors newbie

    Joined:
    Mar 21, 2012
    #14
    I used the posted lsof(1) command to see what was accessing it. It was mds, so then I did a "sudo killall mds" and was able to eject.

    But this was never a problem before El Capitan! They broke something, and it would be really nice if they'd fix it.
     
  15. Asauce macrumors newbie

    Joined:
    Jan 5, 2016
    #15
    Ugh, after 3 hours of trying to figure out the problem I also tried the lsof/killall method and it luckily worked.

    This is so frustrating. I quit all programs in my external drive, checked some of the running operations in activity monitor, and took the drive out of spotlights search index.

    mds seems to be a common problem for all WD drives, luckily it is completely harmless to quit the program. The unfortunate part is it might be different case to case.

    I am also running a VM off my WD drive, and there was also some background operations happening, despite closing all the software associated with the drive. Personally I had to terminate mds, as well as thnuclnt, and finally my drive was free!

    So definitely if you are still having problems open up the terminal and type in the following line of code: (This will list all background activity in the Drive):

    sudo lsof | grep /Volumes/DriveName

    Then terminate all of the activity that is still running using the same code tokyojimu used:

    "sudo killall mds"

    Just make sure that the activity you are deleting is not vital to your comp/drive
     
  16. johnsawyercjs, Mar 9, 2016
    Last edited: Mar 9, 2016

    johnsawyercjs macrumors member

    johnsawyercjs

    Joined:
    Feb 27, 2007
    #16
    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:public.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.
     
  17. Tulula77 macrumors newbie

    Tulula77

    Joined:
    Jun 14, 2016
    #17
    Well, so if that is true, you will hate me then. Thank you so much for helping me. I had the same bloody issue, and it was fixed. Thank you for posting a solution
     

Share This Page