Among the rough edges in macOS is that infuriating message you may see when you try to eject or unmount a volume: it failed because the volume is in use. Not only can you encounter this in the Finder, but it can also prevent running First Aid in Disk Utility, which may report that it couldn’t because it was unable to unmount the volume you want checked. So what can you do about this?

In Disk Utility, the answer seems to be to try again, several times if necessary. It’s unusual for this not to work at all, although it may take a couple of attempts. This seems to be improving steadily, and less likely to occur in Big Sur than Catalina, for example. It’s also worth double-checking the volume that you’re trying to run First Aid on: if it’s one of the current boot volume group, System or Data, then you’re probably better off doing this in Recovery mode anyway.

When it has occurred in the Finder, solutions are harder to come by. What you really want to know is which file(s) are open on the volume, so you have a clue as to what to quit to enable the volume to be ejected cleanly. Don’t just pull the cable of an external disk: not only will your Mac complain, but you could end up damaging the contents of that file, or even the file system on that volume.

To discover which files are open on any volume, use the command
sudo lsof /Volumes/myVol
where myVol is the name of the volume. Once you’ve entered that, type your admin user password at the prompt, and you’ll see a list with entries like
mds 100 root 33r DIR 1,38 192 2 /Volumes/External2
mds 100 root 35u REG 1,38 0 87 /Volumes/External2/.Spotlight-V100/Store-V2/3DD5246F-9AEA-4F0E-9A53-AA63783C3C70/journalExclusion
which are the files and directories open on that volume. This needs to be run using sudo, as otherwise you won’t see any files which are opened by processes running as root, which are most often the offenders.

Some recommend using grep, as in
sudo lsof | grep /Volumes/myVol
but lsof is capable of doing its own filtering.

The information given about each open file contains, from the left:

• an abbreviated name of the command associated, here mds, the Spotlight metadata server;
• the open mode, as the single character following two digits, e.g. 33r is opened for read access only, while 35u is opened for read and write access;
• the type, DIR meaning directory, and REG meaning a regular file;
• the full path to the file or directory.

With a bit of luck, these should provide sufficient clues as to what’s preventing ejection, thus what you can do about it.

Postscript

Thank you to everyone who has suggested alternatives, particularly apps. My personal favourite of them all is Sloth, from here. Although it’s not notarized, it does everything that I’d want in terms of matching lsof or fuser’s features. Most importantly, if you click its padlock at the lower right and authenticate, it will show all processes running as root. Unfortunately, it currently doesn’t distinguish between real volumes and snapshots; although that can have its advantages, it does make it messy to select the volume you want to check. Thanks to charlie for suggesting this.

I’m very grateful to Andy Ihnatko @Ihnatko for reminding me of this use of lsof and to hhanche for pointing out that you don’t need to grep at all.