MacOS: Can't Eject External Drive

For years, I have frequently received the pop-up “The disk ‘XXX’ wasn’t ejected because one or more
programs may be using it.” It has never ceased to amaze me that this powerful computer that I have at my beck and call can’t tell me which programs are “using it.”

All they would need to do is give a message “The disk ‘XXX’ wasn’t ejected because the following
programs may be using it,” then give a list of them. Doesn’t the OS know why the disk can’t be ejected?

Rant over!

1 Like

Yes, the OS knows what processes are using a file, and that includes its folder and volume information. If you open a file in an external drive, run ‘lsof’ and grep for the volume name,you will find the application that has that file opened.

So yes, the Finder could report that information, and in fact it is doing it! (macOS 11.6)

Screenshot 2022-06-24 at 11.10.10

Of course this does not match what you described and I am not taking you for a fool. What are the steps you do that make the Finder not report the offending app?

1 Like

Interesting. I’m using 12.5 and I got the exact message I posted in my OP.

@tonycr I get the same pop-up as you (MacOS 13 beta - I also used to get the same message in previous versions of MacOS). To test this I opened an image in Preview from the external SSD. Then I closed the file which left Preview open. Next, I tried to eject the external SSD at which point the following dialog appeared. So if MacOS knows which application is preventing the disk from being ejected, it is sure not stating so.

As I understand it, the two reported dialog boxes are each used in different situations. The dialog reported by @pantulis is displayed when a certain single program is absolutely blocking the disk from being ejected. However, the more obscure message in the other reported dialog is used when the system is unsure. Notice that in the bottom left corner there is a spinner with the text “trying to eject” as well as the language “may be using it” in the main message. Those both suggest that the system thinks there may be a possibility that the disk could still be ejected and it is trying to resolve that. I find that this dialog will usually appear if I try to eject a disk immediately after closing a program that would have blocked it. My assumption is that the system has not yet cleaned up after the closed program, and so there are still pointers to the disk in memory (or something of the sort). The system is unsure because those pointers don’t belong to any running program. The “trying to eject” is actually cleaning up and checking to see if any such pointers still exist. If none do, then the dialog will close and the disk will be ejected. However, if cleanup fails to remove all pointers, you still have the option to “Force Eject” the disk. Yes, you will break the pointers still in memory, but if they belong to a closed program (which probably has a bug that lead to cleanup failing), then that should be okay. As least the bug in the closed program doesn’t completely block you from ejecting the disk.

2 Likes

This is such a wonderful explanation. Thank you.

Every once in a while, “Force Eject” doesn’t work.

Notice that the message reports “one or more programs.” It could be that cleanup has removed all but one valid blocking program. Try canceling and then ejecting again. You may find that the second time you will get the other dialog which reports the one still-running program which is actually blocking. Of course, that assumes there is only one program actually blocking the eject. If there are more than one, you will likely always get the more obscure message, which is less than ideal. At that point, you can resort to the command line to find the cause.

1 Like

Thanks for the info. I am new to this - very interesting.

So - I opened just one file on external with Visual Studio Code App - then in terminal I typed:

lsof | grep /Volumes/Backup

and it listed 1 thing:

86Z3GCJ4M 1061 me 8r DIR 1,37 384 …

but I didn’t see the app name = Visual Studio Code App

I am not great with terminal - any help would be appreciated…

It seems that --at least on external volumes-- Visual Studio Code does not keep the file descriptors “open” at the OS level :-? I also cannot find Code in the ‘lsof’ command and have even managed to edit a file on an external disk and eject that disk while VS Code has the file open and Finder did not complain! Of course after editing and trying to save the file, Code complained that it could not write the file.

The reason could be that Code opens the file, read its content into a text buffer, and then closes it. Also it “subscribes” to changes on the file itself so if you edit it in an external editor like Textmate or something like that, as soon as you write the file, Code will refresh the text buffer automatically, which is kind of cool!

I don’t think you are doing anything wrong, it’s only that VS Code is the strangest beast. Can you “practice” with a file open in preview and see if you get the file?

1 Like

I am guessing that you are right about your assumptions about VSCode reading into a buffer and closing it.

I did try same with Preview and DID see Preview listed in the results.

Thanks much for the help!

1 Like