Mounting, Ejecting, and Apps That Get in the Way
Why does ejecting sometimes show a window listing other apps?
A volume cannot be unmounted while any process is using it. Before ejecting, the app checks what is holding the volume open and, if anything is, shows a window listing the holders so you can decide. Two kinds of "holding" appear:
- "N open files" — the app genuinely has files on the volume open (this includes apps running from the volume: their executable counts as an open file).
- "has current directory in volume" — the process merely has its working
directory there. The classic case is a Terminal shell sitting in the
volume's folder: it holds no file open, but it still blocks eject. Type
cd ~in that shell (or let the app quit it) and the block disappears.
Clicking the confirm button asks all listed apps to quit, then ejects. An app that refuses to quit (e.g. it's showing an unsaved-changes dialog) is flagged, and a per-row Force Quit button is offered as the escape hatch — use it knowing that force-quitting an app discards that app's unsaved state.
One subtlety about the file counts: the listing is per-volume-filesystem, so an app appears if it has any file open anywhere on that volume, not just in the specific subfolder you're looking at.
I ejected from Finder and got "eject failed" — but the disk ejected anyway. What happened?
Working as intended, if a little ugly. For volumes with Save to Disk
enabled, the app must run a save before the unmount. When the eject
request comes from outside the app (Finder sidebar, diskutil unmount,
umount), the app blocks that request — which is what Finder reports as a
failure — then performs the save and completes the eject itself a moment
later. The end state is exactly what you asked for: data saved, disk
ejected. The transient Finder message is the cost of guaranteeing the save
runs no matter which surface initiated the eject.
This interception only applies to cooperative ejects. It cannot protect against force-ejects or the device disappearing out from under the system.
What happens if a disk gets unmounted behind the app's back?
If something unmounts a volume in a way the app couldn't intercept, the app notices — typically within a second or two, at worst within about five — and updates the volume to "unmounted" in the UI. No save ran in that case, so the folder holds the last saved state, and the last periodic-sync snapshot (if any) is in Application Support. If the newest data was in RAM, treat it like the crash scenario in Data safety — including the advice to rescue the snapshot before remounting.
Does "Mount at launch" mount my disks at boot?
At app launch. Combine it with Open at Login (so the app itself starts when you log in) to get effective mount-at-login. In menu-bar mode this is invisible — no window opens; the disks are simply mounted by the time you look for them.
At each launch the app also reconciles its records against reality: a volume the system still shows as mounted (e.g. the app crashed and relaunched while the tmpfs survived) is picked up as mounted rather than mounted twice, and a volume that vanished while the app was away is marked unmounted.
Does an unmounted RAMDisk still use memory?
No. Unmounting (ejecting) releases the disk's memory back to the system. That is the main reason to eject RAMDisks you're not actively using — mounted disks hold their content in RAM even when idle. See Memory & sizing for how much that actually is.
Can I mount the same folder as two different volumes, or nest volumes?
No. The app rejects creating a volume whose folder is already registered to another volume, already a mount point, or inside a macOS-reserved location. Each volume owns exactly one folder.
The app quit (or crashed) while my disk was mounted. Is the disk gone?
No — the mounts live in the kernel, not in the app. The disk stays mounted and usable. When the app next launches it recognizes the volume as already mounted and simply reattaches to it. Eject remains the moment your data gets saved, so don't treat an app crash as an excuse to skip a clean eject.